Session description protocol mechanisms for signaling radio access network capabilities in multimedia telephony sessions

ABSTRACT

Systems, apparatuses, methods, and computer-readable media are provided for negotiating Radio Access Network (RAN)-level capabilities toward improving end-to-end quality of Internet Protocol Multimedia Subsystem (IMS) communication sessions, such as Voice over Long-Term Evolution (VoLTE) calls. Disclosed embodiments include Session Description Protocol-based mechanisms to signal the RAN-level capabilities. The RAN-level capabilities may include, for example, delay budget information signaling, Transmission Time Interval bundling, RAN frame aggregation, RAN-assisted codec adaptation or access network bitrate recommendation, and/or other like capabilities. Other embodiments may be described and/or claimed.

RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 16/408,360, filed May 9, 2019, entitled “SESSION DESCRIPTIONPROTOCOL MECHANISMS FOR SIGNALING RADIO ACCESS NETWORK CAPABILITIES INMULTIMEDIA TELEPHONY SESSIONS,” which is a continuation of U.S. patentapplication Ser. No. 16/353,783, filed Mar. 14, 2019, entitled “SESSIONDESCRIPTION PROTOCOL MECHANISMS FOR SIGNALING RADIO ACCESS NETWORKCAPABILITIES IN MULTIMEDIA TELEPHONY SESSIONS,” which claims priorityunder 35 U.S.C. § 119 to U.S. Provisional App. No. 62/643,541 filed Mar.15, 2018, the contents of which are hereby incorporated by reference intheir entireties.

FIELD

Various embodiments of the present application generally relate to thefield of wireless communications, and in particular, to MultimediaTelephony Service for IMS technologies.

BACKGROUND

MTSI supports conversational speech, video, and text transported overRTP to deliver a user experience equivalent to or better than that ofcircuit switched conversational services using the same amount ofnetwork resources. MTSI defines media handling (e.g., signaling,transport, jitter buffer management, packet-loss handling, andadaptation), as well as interactivity (e.g., adding or dropping mediaduring a call). The focus is to ensure a reliable and interoperableservice with a predictable media quality, while allowing for flexibilityin the service offerings. MTSI uses SIP, SDP, and SDP capabilitiesnegotiation protocols for media negotiation and configuration. Nosignaling mechanisms are currently defined to provide e2e coordinationbetween UEs with respect to radio capabilities.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 depicts an architecture of a system of a network in accordancewith some embodiments.

FIG. 2 illustrates an example Multimedia Telephony Service for IMSarchitecture according to various embodiments.

FIG. 3 depicts an example use case for RAN delay budget reporting.

FIG. 4 depicts an example procedure for RAN delay budget reporting inMTSI according to some embodiments.

FIG. 5 shows an example bitmask, which may be used for SDP-basednegotiation of RAN capabilities, in accordance with various embodiments.

FIG. 6 depicts an example of infrastructure equipment in accordance withvarious embodiments.

FIG. 7 depicts example components of a computer platform in accordancewith various embodiments.

FIG. 8 depicts a block diagram illustrating components, according tosome example embodiments, able to read instructions from amachine-readable or computer-readable medium (e.g., a non-transitorymachine-readable storage medium) and perform any one or more of themethodologies discussed herein.

FIG. 9 depicts example components of baseband circuitry and radiofrequency circuitry in accordance with various embodiments.

FIG. 10 is an illustration of various protocol functions that may beused for various protocol stacks in accordance with various embodiments.

FIG. 11 depicts example bit rate recommendation MAC CEs according tovarious embodiments.

FIGS. 12-13 depict example processes for practicing the variousembodiments discussed herein.

DETAILED DESCRIPTION

Embodiments herein are related to SDP-based mechanisms to signalspecific RAN-level capabilities toward improving e2e quality ofVoLTE/ViLTE calls. Signaled RAN-level capabilities may include, forexample, Delay Budget Reporting, TTI bundling, RAN frame aggregation,RAN-assisted codec adaptation, etc. According to various embodiments, afirst UE is operable to perform multimedia telephony with a second UE,wherein the second UE is remote from the first UE. The first UE isconfigured to receive an SDP offer message from the second UE with anattribute describing radio capabilities of the second UE, and send anSDP answer message to the second UE with an attribute describing theradio capabilities of the first UE. In some embodiments, the attributedescribing radio capabilities includes descriptors, configurations,and/or parameters pertaining to specific RF circuitry or modem (orbaseband circuitry) capabilities. In some embodiments, the specific RFcircuitry or modem (or baseband circuitry) capabilities include one ormore of a delay budget reporting capability, a TTI bundling capability,a RAN frame aggregation and RAN-assisted codec adaptation capability,and/or other like capabilities. Other embodiments may be describedand/or claimed.

Referring now to FIG. 1, in which an example architecture of a system100 of a network according to various embodiments, is illustrated. Thefollowing description is provided for an example system 100 thatoperates in conjunction with the LTE system standards and 5G or NRsystem standards as provided by 3GPP technical specifications. However,the example embodiments are not limited in this regard and the describedembodiments may apply to other networks that benefit from the principlesdescribed herein, such as future 3GPP systems (e.g., Sixth Generation(6G)) systems, IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc.), or thelike.

As shown by FIG. 1, the system 100 includes UE 101 a and UE 101 b(collectively referred to as “UEs 101” or “UE 101”). In this example,UEs 101 are illustrated as smartphones (e.g., handheld touchscreenmobile computing devices connectable to one or more cellular networks),but may also comprise any mobile or non-mobile computing device, such asconsumer electronics devices, cellular phones, smartphones, featurephones, tablet computers, wearable computer devices, personal digitalassistants, pagers, wireless handsets, desktop computers, laptopcomputers, in-vehicle infotainment, in-car entertainment devices, anInstrument Cluster, head-up display (HUD) devices, onboard diagnosticdevices, dashtop mobile equipment, mobile data terminals, ElectronicEngine Management System, electronic/engine control units,electronic/engine control modules, embedded systems, microcontrollers,control modules, engine management systems, networked or “smart”appliances, MTC devices, M2M, IoT devices, and/or the like. As discussedin more detail infra, the UEs 101 (and the RAN nodes 111) incorporatethe SDP-based signaling embodiments discussed herein. In theseembodiments, the UEs 101 are capable of, inter alia, signaling specificRAN-level capabilities using SDP toward improving e2e quality of VoLTEcalls. The RAN-level capabilities may include, for example, delay budgetreporting, TTI bundling, RAN frame aggregation, RAN-assisted codecadaptation, and/or the like. These and other embodiments are discussedin more detail infra.

In some embodiments, any of the UEs 101 may be IoT UEs, which maycomprise a network access layer designed for low-power IoT applicationsutilizing short-lived UE connections. An IoT UE can utilize technologiessuch as M2M or MTC for exchanging data with an MTC server or device viaa PLMN, ProSe or D2D communication, sensor networks, or IoT networks.The M2M or MTC exchange of data may be a machine-initiated exchange ofdata. An IoT network describes interconnecting IoT UEs, which mayinclude uniquely identifiable embedded computing devices (within theInternet infrastructure), with short-lived connections. The IoT UEs mayexecute background applications (e.g., keep-alive messages, statusupdates, etc.) to facilitate the connections of the IoT network.

The UEs 101 may be configured to connect, for example, communicativelycouple, with an or RAN 110. In embodiments, the RAN 110 may be an NG RANor a 5G RAN, an E-UTRAN, or a legacy RAN, such as a UTRAN or GERAN. Theterm “NG RAN” or the like refers to a RAN 110 that operates in an NR or5G system 100, and the term “E-UTRAN” or the like refers to a RAN 110that operates in an LTE or 4G system 100. The UEs 101 utilizeconnections (or channels) 103 and 104, respectively, each of whichcomprises a physical communications interface or layer.

In this example, the connections 103 and 104 are illustrated as an airinterface to enable communicative coupling, and can be consistent withcellular communications protocols, such as a GSM protocol, a CDMAnetwork protocol, a PTT protocol, a POC protocol, a UMTS protocol, a3GPP LTE protocol, a 5G protocol, a NR protocol, and/or any of the othercommunications protocols discussed herein. In embodiments, the UEs 101may directly exchange communication data via a ProSe interface 105. TheProSe interface 105 may alternatively be referred to as a SL interface105 and may comprise one or more logical channels, including but notlimited to a PSCCH, a PSSCH, a PSDCH, and a PSBCH.

The UE 101 b is shown to be configured to access an AP 106 (alsoreferred to as “WLAN node 106,” “WLAN 106,” “WLAN Termination 106,” “WT106” or the like) via connection 107. The connection 107 can comprise alocal wireless connection, such as a connection consistent with any IEEE802.11 protocol, wherein the AP 106 would comprise a WiFi® router. Inthis example, the AP 106 is shown to be connected to the Internetwithout connecting to the core network of the wireless system (describedin further detail below). In various embodiments, the UE 101 b, RAN 110,and AP 106 may be configured to utilize LWA operation and/or LWIPoperation. The LWA operation may involve the UE 101 b in RRC_CONNECTEDbeing configured by a RAN node 111 a-b to utilize radio resources of LTEand WLAN. LWIP operation may involve the UE 101 b using WLAN radioresources (e.g., connection 107) via IPsec protocol tunneling toauthenticate and encrypt packets (e.g., IP packets) sent over theconnection 107. IPsec tunneling may include encapsulating the entiretyof original IP packets and adding a new packet header, therebyprotecting the original header of the IP packets.

The RAN 110 can include one or more AN nodes or RAN nodes 111 a and 111b (collectively referred to as “RAN nodes 111” or “RAN node 111”) thatenable the connections 103 and 104. These access nodes can be referredto as BS, gNBs, RAN nodes, eNBs, NodeBs, RSUs, TRxPs or TRPs, and soforth, and can comprise ground stations (e.g., terrestrial accesspoints) or satellite stations providing coverage within a geographicarea (e.g., a cell). The term “NG RAN node” or the like refers to a RANnode 111 that operates in an NR or 5G system 100 (for example, a gNB),and the term “E-UTRAN node” or the like refers to a RAN node 111 thatoperates in an LTE or 4G system 100 (e.g., an eNB). According to variousembodiments, the RAN nodes 111 may be implemented as one or more of adedicated physical device such as a macrocell base station, and/or a lowpower base station for providing femtocells, picocells or other likecells having smaller coverage areas, smaller user capacity, or higherbandwidth compared to macrocells.

In some embodiments, all or parts of the RAN nodes 111 may beimplemented as one or more software entities running on server computersas part of a virtual network, which may be referred to as a CRAN and/ora vBBUP. In these embodiments, the CRAN or vBBUP may implement a RANfunction split, such as a PDCP split wherein RRC and PDCP layers areoperated by the CRAN/vBBUP and other L2 protocol entities are operatedby individual RAN nodes 111; a MAC/PHY split wherein RRC, PDCP, RLC, andMAC layers are operated by the CRAN/vBBUP and the PHY layer is operatedby individual RAN nodes 111; or a “lower PHY” split wherein RRC, PDCP,RLC, MAC layers and upper portions of the PHY layer are operated by theCRAN/vBBUP and lower portions of the PHY layer are operated byindividual RAN nodes 111. This virtualized framework allows the freed-upprocessor cores of the RAN nodes 111 to perform other virtualizedapplications. In some implementations, an individual RAN node 111 mayrepresent individual gNB-DUs that are connected to a gNB-CU viaindividual F1 interfaces (not shown by FIG. 1). In theseimplementations, the gNB-DUs may include one or more remote radio headsor RFEMs (see, e.g., FIG. 6), and the gNB-CU may be operated by a serverthat is located in the RAN 110 (not shown) or by a server pool in asimilar manner as the CRAN/vBBUP. Additionally or alternatively, one ormore of the RAN nodes 111 may be next generation eNBs (ng-eNBs), whichare RAN nodes that provide E-UTRA user plane and control plane protocolterminations toward the UEs 101, and are connected to a 5GC 120 via anNG interface.

In V2X scenarios one or more of the RAN nodes 111 may be or act as RSUs.The term “Road Side Unit” or “RSU” refers to any transportationinfrastructure entity used for V2X communications. An RSU may beimplemented in or by a suitable RAN node or a stationary (or relativelystationary) UE. In one example, an RSU is a computing device coupledwith RF circuitry located on a roadside that provides connectivitysupport to passing vehicle UEs 101 (vUEs 101). The RSU may also includeinternal data storage circuitry to store intersection map geometry,traffic statistics, media, as well as applications/software to sense andcontrol ongoing vehicular and pedestrian traffic. The RSU may operate onthe 5.9 GHz Direct Short Range Communications (DSRC) band to providevery low latency communications required for high speed events, such ascrash avoidance, traffic warnings, and the like. Additionally oralternatively, the RSU may operate on the cellular V2X band to providethe aforementioned low latency communications, as well as other cellularcommunications services. Additionally or alternatively, the RSU mayoperate as a Wi-Fi hotspot (2.4 GHz band) and/or provide connectivity toone or more cellular networks to provide uplink and downlinkcommunications. The computing device(s) and some or all of theradiofrequency circuitry of the RSU may be packaged in a weatherproofenclosure suitable for outdoor installation, and may include a networkinterface controller to provide a wired connection (e.g., Ethernet) to atraffic signal controller and/or a backhaul network.

Any of the RAN nodes 111 can terminate the air interface protocol andcan be the first point of contact for the UEs 101. In some embodiments,any of the RAN nodes 111 can fulfill various logical functions for theRAN 110 including, but not limited to, RNC functions such as radiobearer management, uplink and downlink dynamic radio resource managementand data packet scheduling, and mobility management. In embodiments, theUEs 101 can be configured to communicate using OFDM communicationsignals with each other or with any of the RAN nodes 111 over amulticarrier communication channel in accordance with variouscommunication techniques, such as, but not limited to, an OFDMAcommunication technique (e.g., for downlink communications) or a SC-FDMAcommunication technique (e.g., for uplink and ProSe or SLcommunications), although the scope of the embodiments is not limited inthis respect. The OFDM signals can comprise a plurality of orthogonalsubcarriers.

In embodiments, the UEs 101 implement or operate a client for MTSIsupporting conversational speech (including DTMF), video, and texttransported over RTP with the scope to deliver a user experienceequivalent to or better than that of Circuit Switched (CS)conversational services using the same amount of network resources. MTSIdefines media handling (e.g., signaling, transport, jitter buffermanagement, packet-loss handling, adaptation, etc.), as well asinteractivity (e.g., adding or dropping media during a call). In theseembodiments, the UEs 101 may connect to the IMS (e.g., AS 130) using3GPP access (e.g., via RAN 110 and CN 120) or using non-3GPP access(e.g., via WLAN 106, Bluetooth, DECT/NG DECT).

According to various embodiments, UEs 101 may communicate with oneanother using VoLTE mechanisms. VoLTE is a standard for high-speedwireless communication, which is based on IMS networks where specificprofiles for control and media planes of voice service over an LTEnetwork may be defined. In various embodiments, SIP is used to conveyinformation during a call setup procedure. SIP is an application-layercontrol protocol for creating, modifying, and terminating sessions(e.g., Internet multimedia conferences, Internet telephone calls, andmultimedia distribution using an offer/answer model) that worksindependently of underlying transport protocols and without dependencyon the type of session that is being established. SIP works in concertwith various protocols for carrying various forms of real-timemultimedia session data such as voice, video, and/or text messages. SIPworks in concert with these protocols by enabling Internet endpoints(referred to as “user agents”) to discover one another and to agree on acharacterization of a session they would like to share. For locatingprospective session participants, and for other functions, SIP enablesthe creation of an infrastructure of network hosts (referred to as“proxy servers”) to which user agents can send registrations,invitations to sessions, and other requests.

SIP messages used to create sessions may carry session descriptions thatallow participants to agree on a set of compatible media types to beused during the communication session. The session descriptions may beformatted according to SDP, wherein media type and parameter negotiationand media setup is performed with SDP that is carried as payload in SIPmessages. SIP employs many aspects of the HTTP request/response model,including reuse of header fields, encoding rules, and status codes ofHTTP. Furthermore, a suitable transport layer protocol may be used toconvey data before session establishment (e.g., audio and/or video asearly media) or during an established session. The transport layerprotocol may include, for example, UDP, TCP, RSTP, SCTP, RTP, SRTP,and/or the like for the transmission of media streams (e.g., voice,video). Moreover, the SIP messages may be encrypted using TLS, SRTP,and/or the like. In some embodiments, another encapsulation protocol,such as RTSP, may be used to convey SDP messages. RTSP is anapplication-level protocol for controlling the delivery of data withreal-time properties. RTSP provides an extensible framework to enablecontrolled, on-demand delivery of real-time data, such as audio andvideo. An RTSP client and server negotiate an appropriate set ofparameters for media delivery, partially using SDP syntax to describethose parameters.

SDP is used to set up a call and create a session, such as a real-timetext, voice, or video call. The purpose of SDP is to convey informationabout media streams in multimedia sessions to allow the recipients of asession description to participate in the session. SDP provides a meansto communicate the existence of a session, and a means to conveysufficient information to enable joining and participating in thesession. Media streams can be many-to-many, and sessions need not becontinually active. An SDP session description includes the following:session name and purpose; time(s) the session is active; the mediacomprising the session; and information needed to receive those media(e.g., addresses, ports, formats, etc.). The session description mayalso include information about the bandwidth to be used by the session,and contact information for the person responsible for the session.

During the creation of the session, two endpoints (e.g., UE 101 a and UE101 b) that are supposed to later on exchange media packets, send eachother SDP offer messages and answer messages so that the two endpointsexchange respective capability information. For example, a sender (e.g.,UE 101 a) may want to understand what kind of decoders the receiver(e.g., UE 101 b) can support, what kind of codecs the receiver cansupport, and so forth. The sender and the receiver need to agree on theparameters to be used during the session, such as the codecs, protocols,payload formats, and other like parameters related to the delivery ofcontent. And on top of it our proposal here is to. According to variousembodiments, various radio capabilities of the UEs 101 may also beindicated during the SDP offer/answer exchanges.

The offer/answer exchange of session descriptions assumes the existenceof a higher layer protocol (e.g., SIP), which is capable of exchangingSDP for the purposes of session establishment between agents. SDPprotocol operation begins when one agent (e.g., UE 101 a) sends aninitial offer to another agent (e.g., UE 101 b). An agent is theprotocol implementation involved in the offer/answer exchange, and thereare at least two agents involved in an offer/answer exchange. An offeris an SDP message sent by an offerer, and an offerer is an agent thatgenerates a session description in order to create or modify a session.An offer is an initial offer if it is outside of any context that mayhave already been established through the higher layer protocol. It isassumed that the higher layer protocol provides maintenance of some kindof context which allows the various SDP exchanges to be associatedtogether.

The agent receiving the offer may generate an answer, or the agent mayreject the offer. An answer is an SDP message sent by an answerer inresponse to an offer, and an answerer is an agent which receives asession description from another agent describing aspects of desiredmedia communication, and then responds to that with its own sessiondescription. The means for rejecting an offer are dependent on thehigher layer protocol. The offer/answer exchange is atomic in that ifthe answer is rejected, the session reverts to the state prior to theoffer, which may be absence of a session. At any time, either agent maygenerate a new offer that updates the session. However, the agents maynot generate a new offer if it has received an offer to which it has notyet answered or rejected. Furthermore, an agent may not generate a newoffer if the agent has generated a prior offer for which it has not yetreceived an answer or a rejection. If an agent receives an offer afterhaving sent one, but before receiving an answer to it, this isconsidered a glare condition. The term “glare” was originally used incircuit switched telecommunications networks to describe the conditionwhere two switches both attempt to seize the same available circuit onthe same trunk at the same time. For purposes of the present disclosure,“glare” may mean that both agents have attempted to send an updatedoffer at the same time.

For example, an originating UE 101 a may generate and send an SIP INVITErequest to be delivered to a terminating UE 101 b. The INVITE requestmessage may include an SDP offer, at least one media description, andone or more radio capabilities of the UE 101 a. The SDP offer mayreflect the capabilities and user preferences of the UE 101 a for thesession. In this example, after the INVITE message is conveyed to theterminating UE 101 b, a response message including response code 180 maybe conveyed to the originating UE 101 b. The response code 180 mayindicate that the destination user agent (e.g., terminating UE 101 b)received the INVITE, and is alerting the user of the terminating UE 101b of the call/session. While the call/session is in a ringing state,early media may be conveyed between the two UEs 101 using a suitablemechanism, such encoding media data in RTP packets and conveying thoseRTP packets according to RTP. Response messages may be sent by a useragent server indicating a result of a received request. Several classesof responses are recognized, determined by the numerical range of resultcodes. For example, the 200 response code may indicate a successfulcompletion of the request and/or may indicate that a call/session hasbeen established in response to the INVITE message. The SIP and/or SDPmessages may include or indicate other information than that describedpreviously such as, for example, user location which is a determinationof the end system to be used for communication, and user availability:determination of the willingness of the called party to engage incommunications.

An SDP session description itself is entirely textual, and includes anumber of lines of text in the form of <type>=<value>. In general,<value> is either a number of fields delimited by a single spacecharacter or a free format string, and is case-significant unless aspecific field defines otherwise. An SDP session description comprises asession level section followed by zero or more media level sections. Thesession level part starts with a “v=” line and continues to the firstmedia level section. Each media-level section starts with an “m=” lineand continues to the next media-level section or end of the wholesession description. Generally, session level values are the default forall media unless overridden by an equivalent media-level value. ExampleSDP session description parameters are shown by table 1.

TABLE 1 SDP Session Descriptions Session level description v=(protocolversion) Specifies the version of Session Description Protocolo=<username><sess-id><sess- Details about the originator andidentification of version><nettype><addrtype><unicast-address> thesession. <username> - user login. <sess-id> - numeric string used asunique identifier for the session <sess-version> - numeric string usedas version number for this session description <nettype> - Text string,specifying the network type, e.g., IN for internet <addrtype> - Textstring specifying the type of the address of originator E.g.IP4 or IP6<unicast-address> - The address of the machine from where the session isoriginating, which can be both FQDN or IP address. s=<session name> Onlyone session name per session description can be specified. It must notbe empty; therefore if no name is assigned to the session, a singleempty space should be used as session name i=< Session information> Onlyone session-level “i” field can be specified in the Session description.The “i” filed can be used in session or media description. It isprimarily intended for labeling media streams when used in mediadescription section. It can be a human readable description u=<URI> TheURI (Uniform Resource Identifier) specified in the “u” filed, is apointer to additional information about the session e=<email address>Email address of person responsible for conference or session p=<phonenumber> Specifies contact information for the person responsible for theconference or session c=<connection information>; c=<nettype> Connectioninformation can be included in <addrtype> <connection-address> Sessiondescription or in media description. A session description MUST containeither at least one “c=” field in each media description or a single“c=” field at the session level. <nettype> A text string describing thenetwork type, e.g., IN for internet. <addrype> A text string describingthe type of the address used in connection- address; E.g., IP4 or IP6.<connection-address> A Multicast IP address is specified including TTL,e.g., 224.2.36.42/127 b=<bwtype>:<bandwidth> Bandwidth field can be usedboth in the session description, specifying the total bandwidth of thewhole session and can also be used in media description, per mediasession. <bwtype> Bandwidth type can be CT; conference total upper limitof bandwidth to be used, or AS; application specific, therefore it willbe the application's concept of maximum bandwidth. <bandwidth> isinterpreted as kilobits per second by default. z=<adjustment time><offset> <adjustment time> To schedule a repeated session that specifiesa <offset> change from daylight saving time to standard time or viceversa, it is necessary to specify difference from the originating timek=<method>:<encryption key> If channel is secure and trusted, SDP can beused to convey encryption keys. A key can be specified for the wholesession or for each media description. a=<attribute>:<value> Zero ormore session attribute lines. Attributes may be defined at“session-level” or at “media- level” or both. Session level attributesare used to advertise additional information that applies to conferenceas a whole. Media level attributes are specific to the media, i.e.advertising information about the media stream Time descriptiont=<start-time>:<value> Specifies the start and stop times for a session.If a session is active at irregular intervals, multiple time entries canbe used r=<repeat interval> <active duration> <offsets Zero or morerepeat times; If a session is to be from start-time> repeated at fixedintervals, the “r” field is used. By default all values should bespecified in seconds, but to make description more compact, time canalso be given in different units, such as days, hours or minutes; e.g.,r = 6 d 2 h 14 m Media description m=<media> <port>/<number of ports><proto> Media name and transport address. This field is <fmt> used inthe media description section to advertise properties of the mediastream, such as the port it will be using for transmitting, the protocolused for streaming and the format or codec. <media> Used to specifymedia type, generally this can be audio, video, text etc. <port> Theport to which the media stream will be sent. Multiple ports can also bespecified if more than 1 port is being used. <proto> The transportprotocol used for streaming, e.g., RTP (real time protocol). <fmt> Theformat of the media being sent, e.g., in which codec is the mediaencoded; e.g., PCMU, GSM etc. i=<media title> media title or informationfield c=<connection information> connection information - optional ifincluded at session level b=<bwtype>:<bandwidth> bandwidth informationk=<method>:<encryption key> encryption key a=<attribute>:<value> zero ormore media attribute lines

Recent voice and video enhancements for LTE include several VoLTE/ViLTEenhancement features including RAN-assisted codec adaptation,VoLTE/ViLTE signaling optimization and VoLTE/ViLTE quality/coverageenhancement. In addition to RAN-assisted codec adaptation, anotherimportant feature is VoLTE quality/coverage enhancement functionality.As part of this functionality, a delay budget reporting framework hasbeen specified so that the VoLTE coverage can be effectively enhanced byrelaxing the air interface delay budget. This involves the UE 101 usingRRC signaling to report DBI. Based on the reported DBI, when the UE 101is in “good” coverage, the RAN node 111 (e.g., an eNB or gNB) canconfigure longer DRX for power saving purpose. When a remote UE 101 isin “bad” coverage, the RAN node 111 (e.g., an eNB or gNB) can reduce DRXcycle in order to reduce e2e delay and jitter, and/or configure theremote UE 101 in the “bad” coverage to increase the retransmission timesin order to reduce the packet loss.

While RAN-layer delay budget reporting allows UEs 101 to locally adjusttheir own air interface delay, such a mechanism does not providecoordination between the UEs 101 to manage delay and jitter on an e2ebasis. In particular, considering the autonomous operation of the MTSIsender and MTSI receiver (as discussed in more detail with respect toFIG. 4), an MTSI receiver's decision to turn cDRX off may be dependenton the remote MTSI sender's ability to leverage the available delaybudget to further improve the reliability of its transmissions. As such,it would be desirable for the UEs 101 to exchange information aboutspecific RAN capabilities that would be relevant in influencing theremote UE's 101 adaptation and impact the e2e quality of the VoLTE call.Such RAN capabilities may include RAN delay budget reporting, TTIbundling, HARQ support and RAN-assisted codec adaptation or ANBR, and/orother like RAN capabilities.

Embodiments herein provide mechanisms to enable SDP-based methods tosignal specific RAN-level capabilities toward improving e2e quality ofVoLTE calls. Signaled RAN-level capabilities may include Delay BudgetReporting, TTI bundling, RAN frame aggregation, RAN-assisted codecadaptation or ANBR, and the like. In various embodiments, a new SDPattribute RANCapabilities' is defined, which includes dedicatedparameters that allow UEs 101 to indicate support for specific RANcapabilities. The RANCapabilities may include individual parameters thatcorrespond to support of each of RAN delay budget reporting, TTIbundling, RAN frame aggregation, RAN-assisted codec adaptation or ANBR,and/or the like. These aspects are discussed in more detail with respectto FIG. 5.

With respect to ANBR, it has been observed that the ANBR procedures, inthe absence of e2e coordination, may suffer from unfavorableconsequences such as relatively high PLR and poor quality. Enabling suche2e coordination may be useful for a UE 101 to learn the ANBRcapabilities of its remote UE 101 and may accordingly determine the mostsuitable media adaptation on its end, for example, in response to ANBRinformation received from its local RAN node 111 (e.g., an eNB and/orgNB). Moreover, as also observed in 3GPP TR 26.919, such signaling canallow the PCF/PCRF when setting GBR<MBR bearers. Furthermore, from aconformance point of view, the LTE_VoLTE_ViLTE_enh test case included in3GPP TS 36.523-1 assumes that if a UE 101 is capable of receiving ANBRinformation then it is also capable of using this ANBR information as anadaptation trigger. Such a conformance point is currently not supportedby the existing media handling requirements on ANBR in 3GPP TS 26.114,where ANBR is an optional/recommended feature, for example, the UE 101is free to ignore ANBR information as an adaptation trigger. The presentdisclosure introduces SDP-based indications of ANBR-capabilities. Inembodiments, if a UE 101 signals the ANBR SDP capability, then the UE101 is capable of receiving ANBR information from its access network andits MTSI client is capable of ANBR as defined in clause 10.7 of 3GPP TS26.144 v16.0.0 (2018 December).

RAN-assisted codec adaptation or ANBR functionality, as defined in 3GPPTS 26.114, 3GPP TS 36.321, and 3GPP TS 38.321 provides a means for theRAN node 111 (e.g., an eNB or gNB) to send a codec adaptation indicationwith recommended bit rate to assist the UE 101 to select or adapt to acodec rate for voice or video. The RAN-assisted codec adaptationmechanism supports the uplink/downlink bit rate increase or decrease.For a bearer associated with configuration of MBR greater than GBR, therecommended uplink/downlink bit rate is within boundaries set by the MBRand GBR of the concerned bearer. For uplink or downlink bit rateadaptation, the RAN node 111 may send a recommended bit rate to the UE101 to inform the UE 101 on the currently recommended transport bit rateon the local uplink or downlink, which the UE 101 may use in combinationwith other information to adapt the bit rate. For example, the UE 101 amay send a bit rate request to the peer UE 101 b via application layermessages as specified in 3GPP TS 26.114, which the peer UE 101 b may usein combination with other information to adapt the codec bit rate. Therecommended bit rate is in kbps at the physical layer at the time whenthe decision is made. The recommended bit rate for UL and DL is conveyedas a MAC CE from the RAN node 111 to the UE 101. Based on therecommended bit rate from the RAN node 111, a UE 101 may initiate an e2ebit rate adaptation with its peer (e.g., another UE 101 or MGW). The UE101 may also send a query message to its local RAN node 111 to check ifa bit rate recommended by its peer can be provided by the RAN node 111.The UE 101 is not expected to go beyond the recommended bit rate fromthe RAN node 111.

According to various embodiments, a session description may include amedia-level SDP attribute to indicate support for ANBR. For example, themedia-level SDP attribute may be “anbr.” Use of ANBR with dynamicbitrate adaptation is described in 3GPP TS 26.144 v16.0.0 (2018December) clause 10.7.3, and related adaptation of sent and receivedmedia is described in 3GPP TS 26.144 v16.0.0 (2018 December) clauses10.7.3.2 and 10.7.3.3, respectively. At the radio signaling level, ANBRsignaling capability, also known as RAN-assisted codec adaptation asspecified in 3GPP TS 36.321 for LTE access and 3GPP TS 38.321 for NRaccess. The embodiments discussed herein allow for little or no e2ecoordination between the UEs 101 on their ANBR-triggered adaptationcapabilities.

If an MTSI client in terminal signals the ANBR attribute in the SDP,then the MTSI client in terminal supports ANBR as described in 3GPP TS26.144 v16.0.0 (2018 December) clause 10.7, including the use of ANBRwith dynamic bitrate adaptation as described in 3GPP TS 26.144 v16.0.0(2018 December) clause 10.7.3. An MTSI client in terminal is an MTSIclient that is implemented in a terminal or UE 101, and an MTSI clientis a function in a terminal (or UE 101) or in a network entity (e.g., aMRFP) that supports MTSI. An MTSI client capable of supporting multiplestreams may be referred to as an “MSMTSI client.” If the MTSI client interminal signals the ANBR attribute in the SDP, then its UE 101 iscapable of RAN-assisted codec adaptation specified in 3GPP TS 36.321 forLTE access and/or 3GPP TS 38.321 for NR access. For LTE access,inclusion of “anbr” in the SDP indicates whether the UE 101 is able toquery and receive ANBR information (for both downlink and uplink ANBR)from its eNB. Likewise, for NR access inclusion of this attributeindicates whether the UE 101 is able to query and receive ANBRinformation. In various embodiments, the “a=anbr” attribute may only beused on media level.

Informing the remote MTSI client via the SDP about the ANBR supportusing the “anbr” attribute helps the remote MTSI client to determine themost suitable media adaptation on its end, this is especially valid ifthe remote MTSI client itself is also capable of performingANBR-triggered adaptation, e.g., in response to ANBR informationreceived from its local RAN node 111 (e.g., an eNB or gNB). As anexample, for ANBR-triggered rate up-switching, an MTSI client may adaptits sent bitrate and also perform CMR/RTCP-APP/TMMBR/TMMBN signalingmore responsively based on the ANBR information it receives from itslocal RAN node 111, if it knows that the remote MTSI client alsosupports ANBR. In the absence of the knowledge of the ANBR capabilitiesof the remote UE 101, an MTSI client may not have dynamic knowledge onthe feasibility of the new bitrate based on ANBR over the access networkof the remote UE 101, and this may not be desirable especially in a rateup-switching scenario. Furthermore, signaling of ANBR capabilities inthe SDP via “a=anbr” can also be useful for the PCF/PCRF when settingGBR<MBR bearers. An example use of the “a=anbr” attribute relative to amedia line is as follows: a=anbr. The IANA registration information forthe “a=anbr” SDP attribute is provided in table 2.

TABLE 2 Contact name, email address, and telephone number:  3GPPSpecifications Manager  3gppContact@etsi.org  +33 (0)492944200 AttributeName (as it will appear in SDP)  anbr Long-form Attribute Name inEnglish:  3GPP access network bitrate recommendation (ANBR) support attribute Type of Attribute  Media level Is Attribute Value subject tothe Charset Attribute?  This Attribute is not dependent on charset.Purpose of the attribute:  This attribute is used to indicate the UE'sability to use ANBR as an  adaptation trigger and also its ability toreceive ANBR information  from the access network. Appropriate AttributeValues for this Attribute:  No values. See clause 6.2.X for detailedusage.

Referring back to FIG. 1, the RAN nodes 111 are configured tocommunicate with one another via interface 112. In embodiments where thesystem 100 is an LTE system (e.g., when CN 120 is an EPC 120), theinterface 112 may be an X2 interface 112. The X2 interface may bedefined between two or more RAN nodes 111 (e.g., two or more eNBs andthe like) that connect to EPC 120, and/or between two eNBs connecting toEPC 120. In some implementations, the X2 interface may include an X2-Uand an X2-C. The X2-U may provide flow control mechanisms for user datapackets transferred over the X2 interface, and may be used tocommunicate information about the delivery of user data between eNBs.For example, the X2-U may provide specific sequence number informationfor user data transferred from a master eNB (MeNB) to an secondary eNB(SeNB); information about successful in sequence delivery of PDCP PDUsto a UE 101 from an SeNB for user data; information of PDCP PDUs thatwere not delivered to a UE 101; information about a current minimumdesired buffer size at the SeNB for transmitting to the UE user data;and the like. The X2-C may provide intra-LTE access mobilityfunctionality, including context transfers from source to target eNBs,user plane transport control, etc.; load management functionality; aswell as inter-cell interference coordination functionality.

In embodiments where the system 100 is a 5G or NR system (e.g., when CN120 is an 5GC 120), the interface 112 may be an Xn interface 112. The Xninterface is defined between two or more RAN nodes 111 (e.g., two ormore gNBs and the like) that connect to 5GC 120, between a RAN node 111(e.g., a gNB) connecting to 5GC 120 and an eNB, and/or between two eNBsconnecting to 5GC 120. In some implementations, the Xn interface mayinclude an Xn-U interface and an Xn-C interface. The Xn-U may providenon-guaranteed delivery of user plane PDUs and support/provide dataforwarding and flow control functionality. The Xn-C may providemanagement and error handling functionality, functionality to manage theXn-C interface; mobility support for UE 101 in a CM-CONNECTED modeincluding functionality to manage the UE mobility for connected modebetween one or more RAN nodes 111. The mobility support may includecontext transfer from an old (source) serving RAN node 111 to new(target) serving RAN node 111; and control of user plane tunnels betweenold (source) serving RAN node 111 to new (target) serving RAN node 111.A protocol stack of the Xn-U may include a transport network layer builton IP transport layer, and a GTP-U layer on top of a UDP and/or IPlayer(s) to carry user plane PDUs. The Xn-C protocol stack may includean application layer signaling protocol (referred to as XnAP) and atransport network layer that is built on SCTP. The SCTP may be on top ofan IP layer, and may provide the guaranteed delivery of applicationlayer messages. In the transport IP layer, point-to-point transmissionis used to deliver the signaling PDUs. In other implementations, theXn-U protocol stack and/or the Xn-C protocol stack may be same orsimilar to the user plane and/or control plane protocol stack(s) shownand described herein.

The RAN 110 is shown to be communicatively coupled to a core network—inthis embodiment, CN 120. The CN 120 may comprise one or more networkelements 122, which are configured to offer various data andtelecommunications services to customers/subscribers (e.g., users of UEs101) who are connected to the CN 120 via the RAN 110. The CN 120includes one or more servers 122, which may implement various corenetwork elements or AFs such as those discussed herein. The componentsof the CN 120 may be implemented in one physical node or separatephysical nodes including components to read and execute instructionsfrom a machine-readable or computer-readable medium (e.g., anon-transitory machine-readable storage medium). In some embodiments,NFV may be utilized to virtualize any or all network node functions viaexecutable instructions stored in one or more computer-readable storagemediums (described in further detail below). A logical instantiation ofthe CN 120 may be referred to as a network slice, and a logicalinstantiation of a portion of the CN 120 may be referred to as a networksub-slice. NFV architectures and infrastructures may be used tovirtualize one or more network functions, alternatively performed byproprietary hardware, onto physical resources comprising a combinationof industry-standard server hardware, storage hardware, or switches. Inother words, NFV systems can be used to execute virtual orreconfigurable implementations of one or more EPC components/functions.

In some embodiments, the CN 120 may be an EPC (referred to as “EPC120”). In these embodiments, the one or more network elements 122 mayinclude or operate one or more an MMES, SGSNs, S-GWs, P-GWs, HSSs,PCRFs, and/or other like LTE core network elements. Additionally, theRAN 110 (referred to as “E-UTRAN 110” or the like) may be connected withthe EPC 120 via an S1 interface 113. In embodiments, the S1 interface113 may be split into two parts, an S1-U interface 114, which carriestraffic data between the RAN nodes 111 and the S-GW, and the S1-MMEinterface 115, which is a signaling interface between the RAN nodes 111and MMES. Additionally, the P-GW within the EPC 120 may route datapackets between the EPC 120 and external networks such as a networkincluding a PDN 130 via an IP interface 125. The PDN 130 may be anoperator external public, a private PDN (e.g., enterprise network,etc.), or an intra-operator PDN (e.g., for provision of IMS and/orIP-CAN services).

In some embodiments, the CN 120 may be a 5GC (referred to as “5GC 120”).In these embodiments, the network elements 122 may implement, interalia, an AUSF, AMF, SMF, NEF, PCF, NRF, UDM, AF, UPF, SMSF, N3IWF, NSSFand/or other like NR NFs. Additionally, the RAN 110 (referred to as“5G-RAN 110,” “NG-RAN 110,” or the like) may be connected with the 5GC120 via an NG interface 113. In these embodiments, the NG interface 113may be split into two parts, an NG-U interface 114, which carriestraffic data between the RAN nodes 111 and a UPF, and the NG-C interface115, which is a signaling interface between the RAN nodes 111 and AMFs.Additionally, the UPF within the 5GC 120 may perform packet routing,filtering, inspection, forwarding, etc., between the 5GC 120 andexternal networks such as a DN 130 via an IP interface 125. The DN 130may represent one or more data networks, including one or more LADNs,and may be an operator external public, a private PDN (e.g., enterprisenetwork, etc.), or an intra-operator PDN, for example, for provision ofIMS and/or IP-CAN services.

The CN 120 is shown to be communicatively coupled to PDN/DN 130 via anIP communications interface 125. The PDN/DN 130 may include one or moreapplication servers, for example, the AS 250 a and 250 b depicted byFIG. 2. The application server(s) comprise one or more physical and/orvirtualized systems for providing functionality (or services) to one ormore clients (e.g., UEs 101) over a network. The server(s) within PDN/DN130 and/or the server(s) 122 may include various computer devices withrack computing architecture component(s), tower computing architecturecomponent(s), blade computing architecture component(s), and/or thelike. The server(s) may represent a cluster of servers, a server farm, acloud computing service, or other grouping or pool of servers, which maybe located in one or more datacenters. The server(s) may also beconnected to, or otherwise associated with one or more data storagedevices (not shown). Moreover, the server(s) may include an operatingsystem (OS) that provides executable program instructions for thegeneral administration and operation of the individual server computerdevices, and may include a computer-readable medium storing instructionsthat, when executed by a processor of the servers, may allow the serversto perform their intended functions. Suitable implementations for the OSand general functionality of servers are known or commerciallyavailable, and are readily implemented by persons having ordinary skillin the art. Generally, the server(s) offer applications or services thatuse IP/network resources. As examples, the server(s) may provide trafficmanagement services, cloud analytics, content streaming services,immersive gaming experiences, social networking and/or microbloggingservices, and/or other like services. In addition, the various servicesprovided by the server(s) 130 may include initiating and controllingsoftware and/or firmware updates for applications or individualcomponents implemented by the UEs 101. The server(s) can also beconfigured to support one or more communication services (e.g., VoIPsessions, PTT sessions, group communication sessions, social networkingservices, etc.) for the UEs 101 via the CN 120.

FIG. 2 illustrates an example Multimedia Telephony Service for IMS(MTSI) architecture 200 according to various embodiments. MTSI (alsoreferred to as “Multimedia Telephony”) is an IMS telephony service thatbuilds on IMS capabilities to establish multimedia communicationsbetween terminals (e.g., UEs 101 a, 101 b) within and in-betweenoperator networks (operator networks 202 a, 202 b). The terminalsconnect to the IMS using either a fixed access network or a 3GPP accessnetwork.

The MTSI architecture 200 includes two operator networks, including anoperator A network 202 a and an operator B network 202 b. In thisexample, operator A network 202 a serves UE 101 a and operator B network202 b serves UE 101 b. The UEs 101 a, 101 b may include MTSI clientsand/or MSMTSI clients. An MTSI client in terminal is an MTSI client thatis implemented in a terminal or UE 101. The term “MTSI client interminal” is used in the present disclosure when entities such as MRFP,MRFC or media gateways are excluded. An MSMTSI client is a multi-streamcapable MTSI client supporting multiple streams. An MTSI client maysupport multiple streams, even of the same media type, without being anMSMTSI client. Such an MTSI client may, for example, add a second videoto an ongoing video telephony session.

Each of the operator networks 202 a and 202 b include RAN 210 (includingRAN 210 a in the operator A network 202 a and RAN 210 b in the operatorB network 202 b) and a PS domain 220 (including PS domain 220 a in theoperator A network 202 a and PS domain 220 b in the operator B network202 b), which may be the same or similar to the RAN 110 and CN 120 ofFIG. 1, respectively. Each of the operator networks include various CSCFmechanisms to route control-plane signaling between the UEs 101 a and101 b involved in a call, including a P-CSCF 230 (including P-CSCF 230 ain the operator A network 202 a and P-CSCF 230 b in the operator Bnetwork 202 b) and a S-CSCF 240 (including S-CSCF 240 a in the operatorA domain and S-CSCF 240 b in the operator B domain). Operator B network202 b includes an I-CSCF 245 b, however, in other embodiments theoperator A network 202 a may also include an I-CSCF. In someembodiments, the operator networks 202 may include other elements thatare not shown by FIG. 2, such as an MFRP, MRFC, MGW, and/or the like.

The P-CSCF 230 is the first contact point for the UE 101 a, 101 b withinthe IMS. An address of the P-CSCF 230 is discovered by UEs using themechanism described in the clause “Procedures related to Local CSCFDiscovery”. The P-CSCF 230 behaves like a proxy (also referred to as“SIP proxy servers” or the like) in that the P-CSCF 230 accepts requestsand services the requests internally or forwards them to an appropriateentity. In particular, the P-CSCF 230 forwards SIP register requestsreceived from the UE 101 to an entry point determined using the homedomain name, as provided by the UE 101, forwards SIP messages receivedfrom the UE 101 to an SIP server (e.g., the S-CSCF 240) whose name theP-CSCF 230 has received as a result of the registration procedure, andforwards the SIP request or response to the UE 101. The P-CSCF 230 maybehave as a UA wherein the P-CSCF 230 may terminate and independentlygenerate SIP transactions in abnormal conditions. The P-CSCF 230 alsoperforms SIP message compression/decompression.

The S-CSCF 240 handles session states in the network. For registration,the S-CSCF 240 may behave as a registrar (also referred to as an “SIPregistration server” or the like) in that the S-CSCF 240 acceptsregistration requests and makes its information available through alocation server (e.g., HSS 224). The S-CSCF 240 also notifiessubscribers about registration changes including the GRUU sets assignedto registered instances. During registration process, the S-CSCF 240provides policy information, if available, for a Public User Identityfrom the HSS 224 to the P-CSCF 230 and/or UE 101. For example, thepolicy information includes MPS IMS Subscription status and policyapplicable to enterprise network subscribers. For session-related andsession-unrelated flows, the S-CSCF 240 provides session control for theregistered endpoint's (e.g., UEs 101) sessions, and rejects IMScommunication to/from Public User Identity(s) that are barred for IMScommunications after completion of registration. The S-CSCF 240 maybehave as a proxy server in that the S-CSCF 240 accepts requests andservices them internally or forwards them on, possibly aftertranslation. The S-CSCF 240 may behave as a UA in that the S-CSCF 240may terminate and independently generate SIP transactions. Based on thedetermined served user, the S-CSCF 240 handles interactions with theservices platforms for the support of services. The S-CSCF 240 providesendpoints with service event related information (e.g., notification oftones/announcement together with location of additional media resources,billing notification).

The I-CSCF 245 b is the contact point within an operator's network(e.g., the operator B network 202 b) for all IMS connections destined toa subscriber of that network operator (e.g., the UE 101 b), or a roamingsubscriber currently located within that network operator's servicearea. The I-CSCF 245 b also generates CDRs for charging and resourceutilization.

Each operator network in the IMS architecture 200 also include an AS 250(including AS 250 a in the operator A network 202 a and AS 250 b in theoperator B network 202 b). The AS 250 may influence and impact the SIPsession on behalf of the services supported by the operator's network.An AS 250 may host and execute services. The AS 250 may resides eitherin the user's home network or in a third party location. The third partycould be a network or simply a stand-alone AS. In the control plane, AS250 provides supplementary services such as call hold/resume, callforwarding, multi-party calls, and/or the like. The AS 250 may be an SIPAS, OSA AS, or CAMEL IM-SSF. The OSA AS does not directly interact withthe IMS network entities but through the OSA SCS-s. The SIP ApplicationServer supports IMS reference points (e.g., ISC, Sh, Ut (not shown byFIG. 2)), in support of an application, is considered as part of the IMCN subsystem. Examples of such ASs are SCC AS and TAS. The AS (SIP AS,OSA SCS, and/or IM-SSF) can communicate with the HSS 224 over the Sh andSi interfaces (not shown by FIG. 2). An S-CSCF to AS interface is usedto provide services residing in an AS, and an I-CSCF to AS interface isused to forward SIP requests destined to a Public Service Identityhosted by the AS directly to that AS.

The HSS/SLF 224 b is a master database wherein the HSS portion of theHSS/SLF 224 (hereinafter referred to as “HSS 224”) includes (or stores)subscription-related information to support the network entitiesactually handling calls/sessions, and the SLF portion of the HSS/SLF 224(hereinafter referred to as “SLF 224”) includes (or stores) informationused to locate the subscription-related information. Although FIG. 2only depicts HSS/SLF 224 b located in the operator B network 202 b, inother embodiments, the operator A network 202 a may also include anHSS/SLF 224. In some embodiments, the SLF is not required such as in asingle HSS environment (e.g., a server farm architecture) or when an AS250 are configured/managed to use pre-defined HSS 224. A home networkmay contain one or several HSSs 224 depending on the number of mobilesubscribers, the capacity of the equipment, and on the organization ofthe network. As an example, the HSS 224 provides support to the callcontrol servers in order to complete the routing/roaming procedures bysolving authentication, authorization, naming/addressing resolution,location dependencies, etc.

The HSS 224 is responsible for holding (or storing) the following userrelated information: user identification, numbering, and addressinginformation; user security information including network access controlinformation for authentication and authorization; user locationinformation at inter-system level wherein the HSS 224 supports the userregistration and stores inter-system location information, etc.; anduser profile information. The HSS 224 also generates user securityinformation for mutual authentication, communication integrity check andciphering. Based on this information, the HSS 224 also supports the callcontrol and session management entities of the different domains andsubsystems of the operator network. The HSS 224 may integrateheterogeneous information, and enable enhanced features in the corenetwork to be offered to the application & services domain, at the sametime hiding the heterogeneity. Furthermore, the HSS 224 includes IPmultimedia functionality, which provides support to control functions ofthe IM subsystem such as the CSCF 230, 240, 245. The IP multimediafunctionality enables subscriber usage of the IM CN subsystem servicesand is independent of the access network used to access the IM CNsubsystem.

The SLF 224 is queried by the I-CSCF 245 b via a Dx interface (not shownby FIG. 2) during the registration and session setup to get the name ofthe HSS 224 containing the required subscriber specific data.Furthermore the SLF 224 is also queried by the S-CSCF 240 via the Dxinterface (not shown by FIG. 2) during registration. The SLF 224 isqueried by the AS 250 via the Dh interface (not shown by FIG. 2) inconjunction with the Sh interface (not shown by FIG. 2) operation to getthe name of the HSS 224 containing the required subscriber specificdata. The SLF 224 is queried by an 3GPP AAA server (not shown by FIG. 2)via the Dw interface (not shown by FIG. 2) to get the name of the HSS224 containing the required subscriber specific data.

As mentioned previously, the UEs 101 may use SIP, SDP, and SDPCapNeg formedia negotiation and configuration. General SIP signaling (see e.g.,3GPP TS 24.229) is used to convey SDP offer and answer messages. The SIPmessages include SDP offer and answer messages in the message bodyportion of the SIP messages. In some implementations, the MTSI client interminal may use the OMA-DM solutions for enhancing SDP negotiation andresource reservation process.

The session setup for RTP transported media may determine, for eachmedia, IP address(es), RTP profile, UDP port number(s); codec(s); RTPPayload Type number(s), RTP Payload Format(s), the maximum bandwidththat is allowed in the session, and/or the like. The session setup mayalso determine ECN usage and any additional session parameters. Thesession setup for UDP transported media without RTP may determine IPaddress(es), UDP port number(s) and additional session parameters.

An MTSI client (e.g., a UE 101) offers at least one RTP profile for eachRTP media stream. Multiple RTP profiles may be offered using SDPCapNeg.For voice and real-time text, the first SDP offer may include at leastthe AVP profile. For video, the first SDP offer for a media type mayinclude at least the AVPF profile. Subsequent SDP offers may includeonly other RTP profiles if it is known from a preceding offer that thisRTP profile is supported by the answerer. The MTSI client may be capableof receiving an SDP offer containing both AVP and AVPF offers in orderto support interworking. The configuration of ECN for media transportedwith RTP for speech and for video.

SDPCapNeg is used to negotiate RTP profiles for all media types whereAVPF is supported. MTSI clients supporting SDPCapNeg may support thecomplete SDPCapNeg framework. SDPCapNeg attributes that are directlyapplicable for the RTP profile negotiation include, inter alia, tcap,pcfg and acfg attributes. For voice and real-time text, SDPCapNeg may beused when offering AVPF the first time for a new media type in thesession since the support for AVPF in the answering client is not knownat this stage. For video, an MTSI client may either offer AVPF and AVPtogether using SDPCapNeg, or the MTSI client may offer only AVPF withoutusing SDPCapNeg. When offering AVP and AVPF using SDPCapNeg, the MTSIclient may offer AVP on the media (m=) line and may offer AVPF usingSDPCapNeg mechanisms. The SDPCapNeg mechanisms are used as follows: Thesupport for AVPF is indicated in an attribute (a=) line using thetransport capability attribute ‘tcap’. AVPF may be preferred over AVP.At least one configuration using AVPF may be listed using the attributefor potential configurations ‘pcfg’.

An invited MTSI client should accept using AVPF whenever supported. IfAVPF is to be used in the session then the MTSI client selects oneconfiguration out of the potential configurations defined in the SDPoffer for using AVPF; indicates in the media (m=) line of the SDP answerthat the profile to use is AVPF; and indicates the selectedconfiguration for using AVPF in the attribute for actual configurations‘acfg’. If AVP is to be used then the MTSI may not indicate anySDPCapNeg attributes for using AVPF in the SDP answer.

The SDP may include bandwidth information for each media stream and alsofor the session in total. The bandwidth information for each mediastream and for the session is defined by the application specificbandwidth modifier as defined in RFC 4566. An MTSI client in terminalmay include the ‘a=bw-info’ attribute in the SDP offer. When accepting amedia type where the ‘a=bw-info’ attribute is included the MTSI clientin terminal may include the ‘a=bw-info’ attribute in the SDP answer ifit supports the attribute. When the ‘a=bw-info’ attribute is supported,the following bandwidth properties may be included for each RTP payloadtype in the SDP: Maximum Supported Bandwidth for sending direction;Maximum Desired Bandwidth for sending direction; Minimum DesiredBandwidth for sending direction; Minimum Supported Bandwidth for sendingdirection; Maximum Supported Bandwidth for receiving direction (withsome exceptions); Maximum Desired Bandwidth for receiving direction;Minimum Desired Bandwidth for receiving direction; and Minimum SupportedBandwidth for receiving direction.

When an MTSI client in terminal receives an SDP offer or answer it maydetermine the maximum sending rate for the selected codec by selectingthe smallest of the following: the bandwidth value, if the b=ASparameter was included in the received SDP offer or answer; the MaximumSupported Bandwidth for the receiving direction, if included in thereceived SDP; the preconfigured data rate for the selected codec, if theMTSI client has been preconfigured by the operator to use a particulardata rate for the selected codec; the maximum data rate for the selectedcodec as determined by examining the codec information (e.g., codec,mode, profile, level) and any other media information (e.g., ptime andmaxptime) included in the received SDP offer or answer. The maximum datarate is determined assuming no extra bandwidth is allowed forredundancy. The maximum sending rate may be further updated by the MTSIclient in terminal based on receiving an indication of the granted QoS.

The MTSI client in terminal may not transmit at a rate above the maximumsending rate. For speech, the MTSI client should transmit using thecodec mode with the highest data rate allowed by the maximum sendingrate, except if limited to a lower codec mode by the initial codec modeprocedures or by adaptation procedures. With respect to ANBR, the SDPoffer/answer re-negotiation may not be used as a replacement for dynamicmedia bitrate adaptation. ANBR contains information on short-termbandwidth and SDP offer/answer re-negotiations should be avoided orminimized since they consume network resources. Therefore, SDPoffer/answer re-negotiation (e.g., in SIP UPDATE) may not be initiatedbased on ANBR information other than in the following cases: thereceived ANBR from the access network is below the established GBR; thereceived ANBR cannot be supported by any of the negotiated codecconfigurations; potentially increased loss and/or delay due to notlowering the bitrate are not acceptable; the MTSI client in terminalsupports one or more codec configurations that supports the receivedANBR; and ANBR messages with values meeting all the aforementionedconditions are received consistently for an extensive period of time(e.g., 5 seconds or more). Then the MTSI client in terminal mayre-negotiate the session to switch to a codec or codec configurationthat can support the lower bitrate in the ANBR (if any); and/or toreduce the number of used RTP streams (e.g., turning off the affectedmedia); and if the session re-negotiation fails, may not initiatefurther re-negotiation based on ANBR for that bearer in the session. Forvideo, if TMMBR/TMMBN are not supported in the session; and for anextensive period of time (e.g., 5 seconds), the MTSI client in terminalconsistently receives ANBR messages with values significantly below thevideo bitrate sent (as estimated by the receiving MTSI client interminal) from the remote peer. Then the MTSI client in terminal mayre-negotiate the session to set the session bitrate for video to a valuecorresponding to the minimum of the received ANBR and GBR (if >0); or toturn the video off.

The UEs 101 may also support adaptive mechanisms, which are used tooptimize the session quality given the current transportcharacteristics. The mechanisms provided in MTSI are bit-rate,packet-rate and error resilience adaptation. These mechanisms can beused in different ways; however, they should only be used when theresult of the adaptation is assumed to increase the session quality evenif e.g., the source bit-rate is reduced. Adaptive mechanisms that actupon measured or signaled changes in the transport channelcharacteristics may be used in a conservative manner. Examples ofmeasured changes in transport characteristics are variations in PLR anddelay jitter. Examples of signaled changes in transport characteristicsare ANBR and ECN Congestion Experienced (ECN-CE) marking in IP packetheaders. A conservative use of adaptation is characterized by a fastresponse to degrading conditions, and a slower, careful upwardsadaptation intended to return the session media settings to the originaldefault state of the session. The long-term goal of any adaptivemechanism is assumed to be a restoration of the session quality to theoriginally negotiated quality. The short-term goal is to maximize thesession quality given the current transport characteristics, even ifthat means that the adapted state of the session will give a lowersession quality compared to the session default state if transported onan undisturbed channel.

Some access networks may provide the MTSI client in terminal with ANBRmessages, separately per local access bearer and separately for thelocal uplink and downlink. An ANBR message is sent to the MTSI client interminal whenever the access network finds it reasonable to inform abouta change in the recommended bitrate, such that the MTSI client interminal is generally provided with up-to-date recommended bitrateinformation. In general, a single access bearer can carry multiple RTPstreams, in which case ANBR applies to the sum of the individual RTPstream bitrates on that bearer. Access networks supporting ANBR may alsosupport a corresponding ANBRQ message, which allows the MTSI client interminal to query the network for updated ANBR information. ANBRQ mayonly be used to query for an ANBR update when media bitrate is to beincreased, not for media bitrate decrease.

The ANBR and ANBRQ messages are conceptual messages that allowsgeneralization of the description between different accesses, forexample, LTE, NR, and wireless LAN. Where ANBR/ANBRQ signaling is to beused, a mapping between the conceptual ANBR/ANBRQ and the actualmessages for each access may be defined. The format of suchaccess-specific ANBR/ANBRQ messages may differ between different typesof access networks, and there may not even exist a one-to-one mapping ofmessages. The bitrate value in ANBR/ANBRQ may include IP and higherlayer overhead, including bitrate used for RTCP signaling, as opposed tofor example, b=AS line in SDP, which does not include RTCP. Otherdefinitions can be used by the individual access network mappings, forexample, including overhead below IP layer that is added by the accessnetwork, and the UE 101 may then perform appropriate value translation,for example, adjusting for use of ROHC and removing the lower layeroverhead.

When using LTE access, ANBR is mapped to a MAC level message named“Recommended bit rate MAC Control Element” sent by the RAN node 111(e.g., an eNB) and applicable to a specific dedicated bearer. Similarly,when using LTE access, ANBRQ is mapped to a MAC level message named“Recommended bit rate query MAC Control Element” sent to the the RANnode 111 (e.g., an eNB) and applicable to a specific, existing dedicatedbearer. An MTSI client in terminal using LTE access may support ANBR andANBRQ signaling. When using NR access, ANBR is mapped to a MAC levelmessage named “Recommended bit rate MAC Control Element” sent by the RANnode 111 (e.g., an gNB) and applicable to a specific logical channelwhich is mapped to the single media flow (e.g., audio or video) to whichthe recommended bit rate applies. Similarly, when using NR access, ANBRQis mapped to a MAC level message named “Recommended bit rate query MACControl Element” sent to the RAN node 111 (e.g., an gNB) and applicableto a specific, existing logical channel which is mapped to the singlemedia flow to which the recommended bit rate applies. An MTSI client interminal using NR access may support ANBR and ANBRQ signaling.

An MTSI client in terminal may use the ANBR message as an adaptationtrigger, taking other available triggers into account. This may applyfor both speech and video, adapting to the lowest bitrate resulting fromany of the possibly multiple, available triggers. An adaptation triggeris used to indicate a currently allowed bitrate. The currently allowedbitrate is the minimum of the bitrate negotiated in SDP offer/answer andthe bitrate allowed after the latest preceeding adaptation (e.g., a lastprevious TMMBR message) that increased or decreased the allowed bitratefor the encoder. When no bitrate reduction trigger is received, thevalue from SDP offer/answer is used. Therefore, the currently allowedbitrate may vary over time. Multiple adaptation trigger algorithms canbe used in parallel, for example ECN-triggered adaptation, adaptationbased on ANBR, and PLR-triggered adaptation. When multiple adaptationalgorithms are used for the rate adaptation, the rate that the MTSIclient is allowed to use should be no higher than any of the ratesdetermined by each adaptation algorithm. A received ANBR message for acertain access bearer and media direction may be considered valid foruse as input to adaptation trigger evaluation until either another ANBRmessage is received for the same access bearer and media direction,until that access bearer is closed, or until the SIP session is eitherre-negotiated or closed. No signaling is currently present to providee2e coordination between the UEs 101 in regards to ANBR support. TheseANBR procedures, in the absence of e2e coordination, may suffer fromunfavorable consequences such as high PLR and poor quality.

The UEs 101 may also support RAN delay budget reporting through the useof RRC signaling to a RAN node 111 (e.g., an eNB or gNB) allows UEs 101to locally adjust air interface delay. Based on the reported delaybudget information, a good coverage UE 101 on the receiving end (e.g.,the UE 101 that contains the MTSI receiver) can reduce its air interfacedelay, for example, by turning off CDRX or via other means. Thisadditional delay budget can then be made available for the sending UE101 (e.g., the UE 101 that contains the MTSI sender), and can be quitebeneficial for the sending UE 101 when it suffers from poor coverage.When the sending UE 101 is in bad coverage, that UE 101 may request theadditional delay from its local RAN node 111 (e.g., an eNB or gNB), andif granted, that UE 101 would utilize the additional delay budget toimprove the reliability of its uplink transmissions in order to reducepacket loss, for example, via suitable repetition or retransmissionmechanisms, and thereby improve end-to-end delay and qualityperformance.

While RAN-layer delay budget reporting allows UEs 101 to locally adjustair interface delay, such a mechanism does not provide coordinationbetween the UEs 101 to manage delay and jitter on an e2e basis. Inparticular, these approaches do not allow UEs 101 to coordinate thedelay adjustments on an e2e basis. To alleviate this issue, embodimentsherein define SDP and/or RTCP signaling to realize the followingcapabilities on signaling of DBI across UEs 101: (i) an MTSI receivercan indicate available delay budget to an MTSI sender, and (ii) an MTSIsender can explicitly request delay budget from an MTSI receiver.

More specifically, the RTCP-based signaling of DBI is composed of adedicated RTCP feedback (FB) message type to carry available additionaldelay budget during the RTP streaming of media, signaled from the MTSIreceiver to the MTSI sender. In addition, the defined RTCP feedbackmessage type may also be used to carry requested additional delay budgetduring the RTP streaming of media, signaled from the MTSI sender to theMTSI receiver. A corresponding dedicated SDP parameter on the RTCP-basedability to signal available or requested additional delay budget duringthe IMS/SIP based capability negotiations is also defined. For example,an MTSI client (e.g., a UE 101) supporting DBI may offer ‘Delay BudgetInformation’ (DBI) signaling in SDP for all media streams containingspeech and/or video. DBI may be offered by including the a=rtcp-fbattribute with the DBI type under the relevant media line scope. DBIsignaling involves RTCP feedback signaling to carry both availableadditional delay budget from the MTSI receiver to the MTSI sender, andrequested additional delay budget from the MTSI sender to the MTSIreceiver. The DBI type in conjunction with the RTCP feedback method maybe expressed with the following parameter: 3gpp-delay-budget. A wildcardpayload type (“*”) may be used to indicate that the RTCP feedbackattribute for DBI signaling applies to all payload types. Here is anexample usage of this attribute to signal DBI relative to a media linebased on the RTCP feedback method: a=rtcp-fb:* 3gpp-delay-budget. TheABNF for rtcp-fb-val corresponding to the feedback type“3gpp-delay-budget” is given as follows:rtcp-fb-val=/“3gpp-delay-budget”. Such RTCP-based signaling of DBI canalso be used by an MTSI receiver to indicate delay budget availabilitycreated via other means such as jitter buffer size adaptation. Thesignaling of available or requested additional DBI may use RTCP feedbackmessages as specified in IETF RFC 4585. The RTCP feedback message isidentified by PT (payload type)=RTPFB (205), which refers toRTP-specific feedback message. The RTCP feedback method may involvesignaling of available or requested additional delay budget in both ofthe immediate feedback and early RTCP modes.

As such, the RTCP feedback message may be sent from the MTSI receiver tothe MTSI sender to convey to the sender the available additional delaybudget from the perspective of the receiver. The recipient UE 101 of theRTCP feedback message (e.g., the UE 101 containing the MTSI sender) maythen use this information in determining how much delay budget it mayrequest from its eNB/gNB over the RAN interface, for example, by usingRRC signaling based on UEAssistanceInformation as discussed in moredetail infra.

FIG. 3 depicts an example use case for RAN delay budget reporting. Theexample of FIG. 3 is a shortening cDRX cycle for a degraded VoLTE call.In FIG. 3, UE 101 a is experiencing “good” radio conditions and isconfigured with 40 ms connected mode DRX (cDRX). Radio conditions may beconsidered “good” (or “better” than threshold radio conditions) if theUE 101 a detects or measures a channel quality and/or signal strength tobe at or above some predefined threshold (within some margin of error),or detects or measures a signal noise or interference to be below apredefined threshold (within some margin of error). Additionally, UE 101b is experiencing “bad” radio conditions and is configured with no cDRX.Radio conditions may be considered “bad” if the UE 101 b detects ormeasures a channel quality and/or signal strength to be below somepredefined threshold (within some margin of error), or detects ormeasures a signal noise or interference to be at or above a predefinedthreshold (within some margin of error). As examples, a bad radiocondition may be declared when a UE 101 detects or determines a highBLER (e.g., at or above a threshold BLER value), a large jitter or delay(e.g., at or above a threshold jitter or delay values), and/or the like.

The example of FIG. 3 may operate as follows. When the UE 101 b detectsbad radio conditions, the UE 101 b may send multiple HARQretransmissions, which may cause long jitter and/or e2e delay at thereceiver UE 101 a. Next, when the UE 101 a detects that VoLTE quality isbad (e.g., large jitter or delay), the UE 101 a suggests to the RAN node111 a to deconfigure cDRX or shorten a cDRX cycle. In response, the RANnode 111 a may adjust the cDRX cycle, and the e2e delay and jitter maybe reduced. According to various embodiments, the UE 101 a may indicateto its local RAN node 111 (e.g., RAN node 111 a in FIG. 3) a cDRX cyclevalue that is different than a currently configured cDRX cycle value. Inthese embodiments, the UE 101 a indicates a preferred cDRX cycle lengthvia a new RRC message, and the RAN node 111 a decides which cDRX cycleto use. A prohibit timer may also be configured by the RAN node 111 a toprevent the UE 101 a from sending the indication too frequently. Next,when the UE 101 b detects that VoLTE e2e delay has dropped, the UE 101 breports a larger delay headroom to RAN node 111 b, and the RAN node 111b may apply more eMTC repetitions and/or more HARQ retransmissions.

In order to realize the solution of FIG. 3, RRC signaling procedureshave been adopted based on the UEAssistanceInformation message (seee.g., tables 4-5 and 7-8 infra) that allows the UE 101 a to signal todelay budget reporting information to the RAN node 111 a as follows: theUE 101 a in good coverage indicates a preference to the RAN node 111 ato reduce the local air interface delay by sending aUEAssistanceInformation message with delayBudgetReport value andindication of Opel to decrease the connected mode DRX cycle length sothat the e2e delay and jitter can be reduced; and the peer UE 101 b inbad coverage can send a UEAssistanceInformation message withdelayBudgetReport value and indication of type2 to its eNB to indicate apreference on Uu air interface delay adjustments. When a UE 101 detectschanges such as e2e MTSI voice quality or local radio quality, the UE101 may inform the eNB its new preference by sendingUEAssistanceInformation messages with updated contents ondelayBudgetReport. Air interface delay adjustments made through RANdelay budget reporting impact the e2e delay and quality performance ofMTSI in 3GPP TS 26.114. MTSI as in 3GPP TS 26.114 currently does notspecify when and how the UEs 101 should use RAN-based delay adjustmentmechanisms in an end-to-end fashion.

RAN delay budget reporting may be used by MTSI UEs 101 in order tolocally adjust air interface delay, towards improving e2e delay andquality performance. RAN delay budget reporting allows a good coverageUE 101 a on the receiving end to reduce its air interface delay byturning off cDRX. This additional delay budget can then be madeavailable for the sending UE 110 a, which suffers from poor coverage.The sending UE 101 b in such poor coverage condition would typicallykeep its cDRX off and seek improving the reliability of its uplinktransmissions. The sending UE 101 a would request the additional delayfrom its local RAN node 111 a using the RAN delay budget reportingprocedures, and if granted, it would utilize the additional delay budgetto improve the reliability of its uplink transmissions in order toreduce packet loss (e.g., via suitable repetition or retransmissionmechanisms).

Toward developing an e2e operational perspective for MTSI, the followingmode of operation is considered. MTSI sender and MTSI receiverindependently use RAN delay budget reporting mechanisms toward adjustingair interface delay in their respective RANs. As such there is nocoordination between them. In the meantime, both sending and receivingUEs 101 utilize available e2e metrics and other information available attheir MTSI client to trigger RAN delay budget reporting.

FIG. 4 depicts an example procedure 400 for RAN delay budget reportingin MTSI according to some embodiments. Procedure 400 involves RAN delaybudget reporting usage for voice in MTSI without DBI signaling. However,aspects of procedure 400 may be applicable to RAN delay budget reportingusage for other media types (e.g., video) in MTSI without DBI signaling.In the example of FIG. 4, the UE 101 a is served by RAN node 111 a whichis communicatively coupled with a first CN 120 a and IMS 130; and the UE101 b is served by RAN node 111 b which is communicatively coupled witha second CN 120 b and IMS 130.

Procedure 400 begins at operation 401 where UE 101 a sends UE 101 b arate request for bitrate R0. The “Request” message in this example is ageneralized application level rate request message that corresponds toCMR or RTCP-APP for voice. Where video is used, the request may also bea generalized application level rate request message that corresponds toRTCP TMMBR for video. At operation 402, UE 101 b sends an RTP media flowwith bitrate R0. In some embodiments, prior to sending the RTP mediaflow at operation 402, the UE 101 b may send a rate notification messageto indicate acceptance of bitrate R0. In these embodiments, thenotification may be a “Notify” message, which is a generalizedapplication level message that corresponds to RTCP TMMBN for video. Atoperation 403, the UE 101 a detects a long delay and jitter.Additionally or alternatively, the UE 101 a may detect a relatively highPLR. At operation 404 (including operations 404A and 404B), the UE 101 adetects relatively good radio conditions locally. For example, RAN node111 a may send a DL ANBR of bitrate R1>R0 to the UE 101 a (e.g.,operation 404B), and the UE 101 a measures a relatively low BLER over alocal radio link based on the monitoring of successful downlink packettransmissions. Additionally or alternatively, the UE 101 a may measuredownlink throughput over the radio air interface that is much higherthan the received bitrate after accounting for the relevant headers. Inthe meantime, UE 101 a detects relatively high packet losses (e.g.,operation 403) after monitoring reception of RTP packets, also bymonitoring RTCP sender and receiver reports, and applying the highestpossible jitter buffer according to the reference JBM subject to the JBMcompliance (performance) requirement(s) of MTSI. The JBM performancerequirements may be a threshold for a CDF of the speech-frame delayintroduced by a reference delay computation algorithm, where the CDFthreshold may be set by shifting the reference delay computationalgorithm CDF 60 ms. The speech-frame delay CDF is defined as:P(x)=Probability (delay_compensation_by_JBM≤x). The video-frame delayCDF may be the same or similar as the speech-frame delay CDF. Hence, UE101 a concludes that the local radio conditions experienced by UE 101 bare relatively poor.

The adaptation of media in RTP streams that the MTSI client in terminalreceives in the downlink direction (e.g., operation 404B) may requiresending application-level messages to adapt the remote media encoderbitrate. When an MTSI client in terminal receives an ANBR message forthe local DL that triggers an adaptation decision (e.g., operation 404Bin FIG. 4), for the case of video and if TMMBR/TMMBN are supported inthe session, then a corresponding TMMBR message requesting the remotemedia sender to change its rate to match the local downlink restrictionmay be sent, as described in clause 10.3.2 of 3GPP TS 26.114 (2018December). For the case of voice, adaptation signaling to match thelocal downlink restriction may be initiated towards the remote mediasender, as described in clause 10.2 of 3GPP TS 26.114 (2018 December).When an MTSI client in terminal receives application signaling forbitrate adaptation related to received media, such as TMMBN (for video),the media receiver receiving a TMMBN with increased bitrate and wherethe remote media sender owns the restriction may re-evaluate itsdownlink adaptation triggers and, if an adaptation decision arrives at alower bitrate value than in the received TMMBN, send a TMMBR with thatlower bitrate. When deciding whether or not to send TMMBR, the mediareceiver may take all available adaptation triggers into account, e.g.,bitrate limit from the most recently received downlink ANBR message. Ifthe media receiver has reason to believe the most recently received ANBRfor its downlink no longer applies, it may send an ANBRQ message for itsdownlink, if supported, to trigger receiving an ANBR message with recentinformation.

At operation 405A, the UE 101 a sends an RRC message including aUEAssistanceInformation message to RAN node 111 a with type-1 to turnoff cDRX. It is assumed that RAN node 111 a grants this request andturns off CDRX for UE 101 a, and at operation 405B, the RAN node 111 asends an ACK to the UE 101 a to indicate that the cDRX has been turnedoff. Turning off cDRX is relevant when PLR is relatively high, which isthe conclusion of UE 101 a in the example of FIG. 4, as per operations403, 404A, and 404B. However, it should be noted that UE 101 a canincrease the JBM depth to compensate the delay if PLR is relatively lowand the detected jitter is relatively high. In this scenario, delaybudget request from the UE 101 a to the RAN node 111 a is not necessaryand UEAssistanceInformation message may not be sent. Moreover, even in arelatively high PLR situation and/or based on other considerations, theUE 101 a may choose not to turn cDRX off, for example, when savingbattery power is critical or otherwise desired.

At operation 406A, the UE 101 b detects relatively high packet losses onits uplink due to poor coverage conditions. For example, the UE 101 bmay measure high BLER over its local radio link based on the monitoringof successful uplink packet transmissions, for example, by monitoringthe HARQ acknowledgements received. At operation 406B, the UE 101 brequests additional delay budget from its local RAN node 111 b in orderto perform additional re-transmissions to increase the reliability ofits UL transmissions. When requesting this additional delay budget, theUE 101 b may also consider e2e RTT measured based on RTCP reports. Inthis example, RAN node 111 b grants the request for additional delaybudget, and at operation 406C, the RAN node 111 b sends an ACK messageto the UE 101 b to indicate acceptance of the additional delay budget.Because the UE 101 a has already turned its cDRX off, it is unlikelythat the JBM constraint at UE 101 a will lead to packet losses inresponse to the increase air interface delay over the RAN 110corresponding to UE 101 b. At operation 407, the UE 101 a measuresreduced e2e delay and jitter. Additionally or alternatively, the UE 101a may detect reduced PLR, in comparison with the PLR detected atoperation 403 (if a PLR was detected at operation 403), and improvedvoice quality. At operation 408, UE 101 b sends an RTP media flow forvoice with bitrate R0. The actions of the UE 101 a in operations403-405B and the actions of UE 101 b in operations 406A-C may becompletely independent, and there may be no coordination between the twoUEs 101 for this autonomous mode of operation.

FIG. 5 shows an example bitmask 500, which may be used for SDP-basednegotiation of RAN capabilities, in accordance with various embodiments.While RAN-layer delay budget reporting allows UEs 101 to locally adjustair interface delay, such a mechanism does not provide coordinationbetween the UEs to manage delay and jitter on an e2e basis. Inparticular, considering the autonomous operation of the MTSI sender andreceiver as described previously, an MTSI receiver's decision to turncDRX off may be dependent on the remote MTSI sender's ability toleverage the available delay budget to further improve the reliabilityof its transmissions. As such, it would be desirable for the UEs 101 toexchange information about specific RAN capabilities that would berelevant in influencing the remote UE's 101 adaptation and impact thee2e quality of the VoLTE call. Such RAN capabilities may include RANdelay budget reporting, TTI bundling, HARQ support, and RAN-assistedcodec adaptation or ANBR, and/or the like.

According to various embodiments, during SDP capability negotiation,each UE 101 may include a RANCapabilities attribute to describe itscapabilities. Using the RANCapabilities attribute, each UE 101 may knowthe other UE's 101 radio capabilities after the SDP offer and answerexchange. Each UE 101 may use this knowledge as part of its media andradio level adaptation. For instance, upon learning during the SDPexchange that the remote UE 101 b (e.g., an MTSI sender) supports delaybudget reporting and TTI bundling, a local UE 101 a (e.g., the MTSIreceiver) may decide to turn off cDRX when it detects good radioconditions locally, but high packet loss on an e2e basis aftermonitoring RTP reception statistics. However, if the remote UE 101 bdoes not support delay budget reporting as indicated in the SDP, thenthe local UE 101 a may decide not to turn of cDRX, since even if cDRXwas turned off, the remote UE 101 b may not be able to make use of theadditional delay budget.

In various embodiments, the RAN capabilities may be signaled in an SDPmessage using the “a=RANCapabilities” attribute at the session level.The following parameters may be provided in the RANCapabilitiesattribute: a Delay Budget field including a Boolean value indicatingwhether the UE 101 supports delay budget reporting; a TTI Bundling fieldincluding a Boolean value indicating whether the UE supports TTIbundling; a RAN frame aggregation field including a Boolean valueindicating whether the UE supports RAN frame aggregation; and RAN_Codecfield including a Boolean value indicating whether the UE supportsRAN-assisted codec adaptation (or ANBR). In the example bitmask 500 ofFIG. 5, the Delay Budget field is included in the bit position 0 (i.e.,the least significant bit), the TTI Bundling field is bit position 1,the RAN frame aggregation field is the 2 bit position, the RAN_Codecfield is bit position 3, and a reserved bit field is in the bit position4. The other bits of the example bitmask 500 may be used to convey otherparameters or other types of information. Additionally, otherarrangements are possible in other embodiments.

In addition to indicating whether various RAN capabilities aresupported, the RANCapabilities attribute may also contain parametersthat describe specific RAN configurations (e.g., that may be configuredby the UE's 101 local RAN node 111) in the UE 101 that may be relevantin influencing the remote UE's 101 adaptation and impact the end to endquality of the VoLTE call. An example use of the RANCababilitiesattribute in the SDP is shown by table 3.

TABLE 3 a=RANCapabilities[Delay_Budget=1,TTI_Bundling=1,RAN_Codec=0]

FIG. 6 illustrates an example of infrastructure equipment 600 inaccordance with various embodiments. The infrastructure equipment 600(or “system 600”) may be implemented as a base station, radio head, RANnode such as the RAN nodes 111 and/or AP 106 shown and describedpreviously, application server(s) 130, and/or any other element/devicediscussed herein. In other examples, the system 600 could be implementedin or by a UE 101. The system 600 includes application circuitry 605,baseband circuitry 610, one or more radio front end modules (RFEMs) 615,memory circuitry 620, power management integrated circuitry (PMIC) 625,power tee circuitry 630, network controller circuitry 635, networkinterface connector 640, satellite positioning circuitry 645, and userinterface 650. In some embodiments, the device 600 may includeadditional elements such as, for example, memory/storage, display,camera, sensor, or I/O interface. In other embodiments, the componentsdescribed below may be included in more than one device. For example,said circuitries may be separately included in more than one device forCRAN, vBBU, or other like implementations.

Application circuitry 605 includes circuitry such as, but not limited toone or more processors (or processor cores), cache memory, and one ormore of low drop-out voltage regulators (LDOs), interrupt controllers,serial interfaces such as SPI, I²C or universal programmable serialinterface module, real time clock (RTC), timer-counters includinginterval and watchdog timers, general purpose I/O, memory cardcontrollers such as Secure Digital (SD) MultiMediaCard (MMC) or similar,USB interfaces, Mobile Industry Processor Interface (MIPI) interfacesand Joint Test Access Group (JTAG) test access ports. The processors (orcores) of the application circuitry 605 may be coupled with or mayinclude memory/storage elements and may be configured to executeinstructions stored in the memory/storage to enable various applicationsor operating systems to run on the system 600. In some implementations,the memory/storage elements may be on-chip memory circuitry, which mayinclude any suitable volatile and/or non-volatile memory, such as DRAM,SRAM, EPROM, EEPROM, Flash memory, solid-state memory, and/or any othertype of memory device technology, such as those discussed herein.

The processor(s) of application circuitry 605 may include, for example,one or more processor cores (CPUs), one or more application processors,one or more graphics processing units (GPUs), one or more reducedinstruction set computing (RISC) processors, one or more Acorn RISCMachine (ARM) processors, one or more complex instruction set computing(CISC) processors, one or more digital signal processors (DSP), one ormore FPGAs, one or more PLDs, one or more ASICs, one or moremicroprocessors or controllers, or any suitable combination thereof. Insome embodiments, the application circuitry 605 may comprise, or may be,a special-purpose processor/controller to operate according to thevarious embodiments herein. As examples, the processor(s) of applicationcircuitry 605 may include one or more Intel Pentium®, Core®, or Xeon®processor(s); Advanced Micro Devices (AMD) Ryzen® processor(s),Accelerated Processing Units (APUs), or Epyc® processors; ARM-basedprocessor(s) licensed from ARM Holdings, Ltd. such as the ARM Cortex-Afamily of processors and the ThunderX2® provided by Cavium™, Inc.; aMIPS-based design from MIPS Technologies, Inc. such as MIPS WarriorP-class processors; and/or the like. In some embodiments, the system 600may not utilize application circuitry 605, and instead may include aspecial-purpose processor/controller to process IP data received from anEPC or 5GC, for example.

In some implementations, the application circuitry 605 may include oneor more hardware accelerators, which may be microprocessors,programmable processing devices, or the like. The one or more hardwareaccelerators may include, for example, computer vision and/or deeplearning accelerators. As examples, the programmable processing devicesmay be one or more FPGAs; programmable logic devices (PLDs) such ascomplex PLDs (CPLDs), high-capacity PLDs (HCPLDs); ASICs such asstructured ASICs; programmable SoCs (PSoCs); and the like. In suchimplementations, the circuitry of application circuitry 605 may compriselogic blocks or logic fabric, and other interconnected resources thatmay be programmed to perform various functions, such as the procedures,methods, functions, etc. of the various embodiments discussed herein. Insuch embodiments, the circuitry of application circuitry 605 may includememory cells (e.g., erasable programmable read-only memory (EPROM),electrically erasable programmable read-only memory (EEPROM), flashmemory, static memory (e.g., static random access memory (SRAM),anti-fuses, etc.)) used to store logic blocks, logic fabric, data, etc.in look-up-tables (LUTs) and the like.

The baseband circuitry 610 may be implemented, for example, as asolder-down substrate including one or more integrated circuits, asingle packaged integrated circuit soldered to a main circuit board or amulti-chip module containing two or more integrated circuits. Thevarious hardware electronic elements of baseband circuitry 610 arediscussed infra with regard to FIG. 9. User interface circuitry 650 mayinclude one or more user interfaces designed to enable user interactionwith the system 600 or peripheral component interfaces designed toenable peripheral component interaction with the system 600. Userinterfaces may include, but are not limited to, one or more physical orvirtual buttons (e.g., a reset button), one or more indicators (e.g.,light emitting diodes (LEDs)), a physical keyboard or keypad, a mouse, atouchpad, a touchscreen, speakers or other audio emitting devices,microphones, a printer, a scanner, a headset, a display screen ordisplay device, etc. Peripheral component interfaces may include, butare not limited to, a nonvolatile memory port, a universal serial bus(USB) port, an audio jack, a power supply interface, etc.

The radio front end modules (RFEMs) 615 may comprise a millimeter wave(mmWave) RFEM and one or more sub-mmWave radio frequency integratedcircuits (RFICs). In some implementations, the one or more sub-mmWaveRFICs may be physically separated from the mmWave RFEM. The RFICs mayinclude connections to one or more antennas or antenna arrays (see e.g.,antenna array 911 of FIG. 9 infra), and the RFEM may be connected tomultiple antennas. In alternative implementations, both mmWave andsub-mmWave radio functions may be implemented in the same physical RFEM615, which incorporates both mmWave antennas and sub-mmWave. The memorycircuitry 620 may include one or more of volatile memory includingdynamic random access memory (DRAM) and/or synchronous dynamic randomaccess memory (SDRAM), and nonvolatile memory (NVM) including high-speedelectrically erasable memory (commonly referred to as Flash memory),phase change random access memory (PRAM), magnetoresistive random accessmemory (MRAM), etc., and may incorporate the three-dimensional (3D)cross-point (XPOINT) memories from Intel® and Micron®. Memory circuitry620 may be implemented as one or more of solder down packaged integratedcircuits, socketed memory modules and plug-in memory cards.

The PMIC 625 may include voltage regulators, surge protectors, poweralarm detection circuitry, and one or more backup power sources such asa battery or capacitor. The power alarm detection circuitry may detectone or more of brown out (under-voltage) and surge (over-voltage)conditions. The power tee circuitry 630 may provide for electrical powerdrawn from a network cable to provide both power supply and dataconnectivity to the infrastructure equipment 600 using a single cable.The network controller circuitry 635 may provide connectivity to anetwork using a standard network interface protocol such as Ethernet,Ethernet over GRE Tunnels, Ethernet over MPLS, or some other suitableprotocol. Network connectivity may be provided to/from theinfrastructure equipment 600 via network interface connector 640 using aphysical connection, which may be electrical (commonly referred to as a“copper interconnect”), optical, or wireless. The network controllercircuitry 635 may include one or more dedicated processors and/or FPGAsto communicate using one or more of the aforementioned protocols. Insome implementations, the network controller circuitry 635 may includemultiple controllers to provide connectivity to other networks using thesame or different protocols.

The positioning circuitry 645 includes circuitry to receive and decodesignals transmitted/broadcasted by a positioning network of a GNSS.Examples of navigation satellite constellations (or GNSS) include UnitedStates' GPS, Russia's GLONASS, the European Union's Galileo system,China's BeiDou Navigation Satellite System, a regional navigation systemor GNSS augmentation system (e.g., Navigation with Indian Constellation(NAVIC), Japan's Quasi-Zenith Satellite System (QZSS), France's DopplerOrbitography and Radio-positioning Integrated by Satellite (DORIS),etc.), or the like. The positioning circuitry 645 comprises varioushardware elements (e.g., including hardware devices such as switches,filters, amplifiers, antenna elements, and the like to facilitate OTAcommunications) to communicate with components of a positioning network,such as navigation satellite constellation nodes. In some embodiments,the positioning circuitry 645 may include a Micro-Technology forPositioning, Navigation, and Timing (Micro-PNT) IC that uses a mastertiming clock to perform position tracking/estimation without GNSSassistance. The positioning circuitry 645 may also be part of, orinteract with, the baseband circuitry 610 and/or RFEMs 615 tocommunicate with the nodes and components of the positioning network.The positioning circuitry 645 may also provide position data and/or timedata to the application circuitry 605, which may use the data tosynchronize operations with various infrastructure (e.g., RAN nodes 111,etc.), or the like.

The components shown by FIG. 6 communicate with one another usinginterface circuitry, which may include interconnect (IX) 606. The IX 606may include any number of bus and/or IX technologies such as industrystandard architecture (ISA), extended ISA (EISA), inter-integratedcircuit (I²C), an serial peripheral interface (SPI), point-to-pointinterfaces, power management bus (PMBus), peripheral componentinterconnect (PCI), PCI express (PCIe), Intel® Ultra Path Interface(UPI), Intel® Accelerator Link (IAL), Common Application ProgrammingInterface (CAPI), Intel® QuickPath interconnect (QPI), Ultra PathInterconnect (UPI), Intel® Omni-Path Architecture (OPA) IX, RapidIO™system IXs, Cache Coherent Interconnect for Accelerators (CCIA), Gen-ZConsortium IXs, Open Coherent Accelerator Processor Interface (OpenCAPI)IX, a HyperTransport interconnect, and/or any number of other IXtechnologies. The IX technology may be a proprietary bus, for example,used in an SoC based system.

FIG. 7 illustrates an example of a platform 700 (or “device 700”) inaccordance with various embodiments. In embodiments, the computerplatform 700 may be suitable for use as UEs 101, application servers130, and/or any other element/device discussed herein. The platform 700may include any combinations of the components shown in the example. Thecomponents of platform 700 may be implemented as integrated circuits(ICs), portions thereof, discrete electronic devices, or other modules,logic, hardware, software, firmware, or a combination thereof adapted inthe computer platform 700, or as components otherwise incorporatedwithin a chassis of a larger system. The block diagram of FIG. 7 isintended to show a high level view of components of the computerplatform 700. However, some of the components shown may be omitted,additional components may be present, and different arrangement of thecomponents shown may occur in other implementations.

Application circuitry 705 includes circuitry such as, but not limited toone or more processors (or processor cores), cache memory, and one ormore of LDOs, interrupt controllers, serial interfaces such as SPI, I²Cor universal programmable serial interface module, RTC, timer-countersincluding interval and watchdog timers, general purpose I/O, memory cardcontrollers such as SD MMC or similar, USB interfaces, MIPI interfaces,and JTAG test access ports. The processors (or cores) of the applicationcircuitry 705 may be coupled with or may include memory/storage elementsand may be configured to execute instructions stored in thememory/storage to enable various applications or operating systems torun on the system 700. In some implementations, the memory/storageelements may be on-chip memory circuitry, which may include any suitablevolatile and/or non-volatile memory, such as DRAM, SRAM, EPROM, EEPROM,Flash memory, solid-state memory, and/or any other type of memory devicetechnology, such as those discussed herein.

The processor(s) of application circuitry 705 may include, for example,one or more processor cores, one or more application processors, one ormore GPUs, one or more RISC processors, one or more ARM processors, oneor more CISC processors, one or more DSP, one or more FPGAs, one or morePLDs, one or more ASICs, one or more microprocessors or controllers, amultithreaded processor, an ultra-low voltage processor, an embeddedprocessor, some other known processing element, or any suitablecombination thereof. The processors (or cores) of the applicationcircuitry 705 may be coupled with or may include memory/storage and maybe configured to execute instructions stored in the memory/storage toenable various applications or operating systems to run on the system700. In these embodiments, the processors (or cores) of the applicationcircuitry 705 are configured to operate application software to providea specific service to a user of the system 700. In some embodiments, theapplication circuitry 705 may comprise, or may be, a special-purposeprocessor/controller to operate according to the various embodimentsherein.

As examples, the processor(s) of application circuitry 705 may includean Intel® Architecture Core™ based processor, such as a Quark™, anAtom™, an i3, an i5, an i7, or an MCU-class processor, or another suchprocessor available from Intel® Corporation, Santa Clara, Calif. Theprocessors of the application circuitry 705 may also be one or more ofAdvanced Micro Devices (AMD) Ryzen® processor(s) or AcceleratedProcessing Units (APUs); A5-A9 processor(s) from Apple® Inc.,Snapdragon™ processor(s) from Qualcomm® Technologies, Inc., TexasInstruments, Inc.® Open Multimedia Applications Platform (OMAP)™processor(s); a MIPS-based design from MIPS Technologies, Inc. such asMIPS Warrior M-class, Warrior I-class, and Warrior P-class processors;an ARM-based design licensed from ARM Holdings, Ltd., such as the ARMCortex-A, Cortex-R, and Cortex-M family of processors; or the like. Insome implementations, the application circuitry 705 may be a part of asystem on a chip (SoC) in which the application circuitry 705 and othercomponents are formed into a single integrated circuit, or a singlepackage, such as the Edison™ or Galileo™ SoC boards from Intel®Corporation. Other examples of the processor circuitry of applicationcircuitry 605 are mentioned elsewhere in the present disclosure.

Additionally or alternatively, application circuitry 705 may includecircuitry such as, but not limited to, one or more FPGAs; programmablelogic devices (PLDs) such as CPLDs, HCPLDs, etc.; ASICs such asstructured ASICs; PSoCs; and the like. In such embodiments, thecircuitry of application circuitry 705 may comprise logic blocks orlogic fabric, and other interconnected resources that may be programmedto perform various functions, such as the procedures, methods,functions, etc. of the various embodiments discussed herein. In suchembodiments, the circuitry of application circuitry 705 may includememory cells (e.g., EPROM, EEPROM, flash memory, static memory (e.g.,SRAM, anti-fuses, etc.)) used to store logic blocks, logic fabric, data,etc. in LUTs and the like.

The baseband circuitry 710 may be implemented, for example, as asolder-down substrate including one or more integrated circuits, asingle packaged integrated circuit soldered to a main circuit board or amulti-chip module containing two or more integrated circuits. Thebaseband circuitry 710 may include circuitry such as, but not limitedto, one or more single-core or multi-core processors (e.g., one or morebaseband processors) or control logic to process baseband signalsreceived from a receive signal path of the RFEMs 715, and to generatebaseband signals to be provided to the RFEMs 715 via a transmit signalpath. In various embodiments, the baseband circuitry 710 may implement areal-time OS (RTOS) to manage resources of the baseband circuitry 710,schedule tasks, etc. Examples of the RTOS may include Operating SystemEmbedded (OSE)™ provided by Enea®, Nucleus RTOS™ provided by MentorGraphics®, Versatile Real-Time Executive (VRTX) provided by MentorGraphics®, ThreadX™ provided by Express Logic®, FreeRTOS, REX OSprovided by Qualcomm®, OKL4 provided by Open Kernel (OK) Labs®, or anyother suitable RTOS, such as those discussed herein. The varioushardware electronic elements of baseband circuitry 710 are discussedinfra with regard to FIG. 9.

The RFEMs 715 may comprise a millimeter wave (mmWave) RFEM and one ormore sub-mmWave radio frequency integrated circuits (RFICs). In someimplementations, the one or more sub-mmWave RFICs may be physicallyseparated from the mmWave RFEM. The RFICs may include connections to oneor more antennas or antenna arrays (see e.g., antenna array 911 ofFigure XT infra), and the RFEM may be connected to multiple antennas. Inalternative implementations, both mmWave and sub-mmWave radio functionsmay be implemented in the same physical RFEM 715, which incorporatesboth mmWave antennas and sub-mmWave.

The memory circuitry 720 may include any number and type of memorydevices used to provide for a given amount of system memory. Asexamples, the memory circuitry 720 may include one or more of volatilememory including RAM, DRAM and/or SDRAM, and NVM including high-speedelectrically erasable memory (commonly referred to as Flash memory),PRAM, MRAM, etc. The memory circuitry 720 may be developed in accordancewith a Joint Electron Devices Engineering Council (JEDEC) low powerdouble data rate (LPDDR)-based design, such as LPDDR2, LPDDR3, LPDDR4,or the like. Memory circuitry 720 may be implemented as one or more ofsolder down packaged integrated circuits, single die package, dual diepackage, or quad die package (Q17P), socketed memory modules, dualinline memory modules (DIMMs) including microDIMMs or MiniDIMMs, and/orsoldered onto a motherboard via a ball grid array. In low powerimplementations, the memory circuitry 720 may be on-die memory orregisters associated with the application circuitry 705. To provide forpersistent storage of information such as data, applications, operatingsystems and so forth, memory circuitry 720 may include one or more massstorage devices, which may include, inter alia, a solid state disk drive(SSDD), hard disk drive (HDD), a micro HDD, resistance change memories,phase change memories, holographic memories, or chemical memories, amongothers. For example, the computer platform 700 may incorporate thethree-dimensional (3D) cross-point (XPOINT) memories from Intel® andMicron®.

Removable memory circuitry 723 may include devices, circuitry,enclosures/housings, ports or receptacles, etc. used to couple portabledata storage devices with the platform 700. These portable data storagedevices may be used for mass storage purposes, and may include, forexample, flash memory cards (e.g., Secure Digital (SD) cards, microSDcards, xD picture cards, and the like), and USB flash drives, opticaldiscs, external HDDs, and the like.

In some implementations, the memory circuitry 720 and/or the removablememory 723 provide persistent storage of information such as data,applications, operating systems (OS), and so forth. The persistentstorage circuitry is configured to store computational logic (or“modules”) in the form of software, firmware, or hardware commands toimplement the techniques described herein. The computational logic maybe employed to store working copies and/or permanent copies of computerprograms (or data to create the computer programs) for the operation ofvarious components of platform 700 (e.g., drivers, etc.), an operatingsystem of platform 700, one or more applications, and/or for carryingout the embodiments discussed herein. The computational logic may bestored or loaded into memory circuitry 720 as instructions (or data tocreate the instructions) for execution by the application circuitry 705to provide the functions described herein. The various elements may beimplemented by assembler instructions supported by processor circuitryor high-level languages that may be compiled into such instructions (ordata to create the instructions). The permanent copy of the programminginstructions may be placed into persistent storage devices of persistentstorage circuitry in the factory or in the field through, for example, adistribution medium (not shown), through a communication interface(e.g., from a distribution server (not shown)), or OTA.

In an example, the instructions provided via the memory circuitry 720and/or the persistent storage circuitry are embodied as one or morenon-transitory computer readable storage media including program code, acomputer program product (or data to create the computer program) withthe computer program or data, to direct the application circuitry 705 ofplatform 700 to perform electronic operations in the platform 700,and/or to perform a specific sequence or flow of actions, for example,as described with respect to the flowchart(s) and block diagram(s) ofoperations and functionality depicted infra (see e.g., FIGS. 12-13). Theapplication circuitry 705 accesses the one or more non-transitorycomputer readable storage media over the IX 706.

Although the instructions and/or computational logic have been describedas code blocks included in the memory circuitry 720 and/or code blocksin the persistent storage circuitry, it should be understood that any ofthe code blocks may be replaced with hardwired circuits, for example,built into an FPGA, ASIC, or some other suitable circuitry. For example,where application circuitry 705 includes (e.g., FPGA based) hardwareaccelerators as well as processor cores, the hardware accelerators(e.g., the FPGA cells) may be pre-configured (e.g., with appropriate bitstreams) with the aforementioned computational logic to perform some orall of the functions discussed previously (in lieu of employment ofprogramming instructions to be executed by the processor core(s)).

The platform 700 may also include interface circuitry (not shown) thatis used to connect external devices with the platform 700. The externaldevices connected to the platform 700 via the interface circuitryinclude sensor circuitry 721 and actuators 722, as well as removablememory devices coupled to removable memory circuitry 723.

The sensor circuitry 721 include devices, modules, or subsystems whosepurpose is to detect events or changes in its environment and send theinformation (sensor data) about the detected events to some other adevice, module, subsystem, etc. Examples of such sensors include, interalia, inertia measurement units (IMUs) comprising accelerometers,gyroscopes, and/or magnetometers; microelectromechanical systems (MEMS)or nanoelectromechanical systems (NEMS) comprising 3-axisaccelerometers, 3-axis gyroscopes, and/or magnetometers; level sensors;flow sensors; temperature sensors (e.g., thermistors); pressure sensors;barometric pressure sensors; gravimeters; altimeters; image capturedevices (e.g., cameras or lensless apertures); light detection andranging (LiDAR) sensors; proximity sensors (e.g., IR radiation detectorand the like), depth sensors, ambient light sensors, ultrasonictransceivers; microphones or other like audio capture devices; etc.

Actuators 722 include devices, modules, or subsystems whose purpose isto enable platform 700 to change its state, position, and/ororientation, or move or control a mechanism or (sub)system. Theactuators 722 comprise electrical and/or mechanical devices for movingor controlling a mechanism or system, and converts energy (e.g.,electric current or moving air and/or liquid) into some kind of motion.The actuators 722 may include one or more electronic (orelectrochemical) devices, such as piezoelectric biomorphs, solid stateactuators, solid state relays (SSRs), shape-memory alloy-basedactuators, electroactive polymer-based actuators, relay driverintegrated circuits (ICs), and/or the like. The actuators 722 mayinclude one or more electromechanical devices such as pneumaticactuators, hydraulic actuators, electromechanical switches includingelectromechanical relays (EMRs), motors (e.g., DC motors, steppermotors, servomechanisms, etc.), wheels, thrusters, propellers, claws,clamps, hooks, an audible sound generator, and/or other likeelectromechanical components. The platform 1000 may be configured tooperate one or more actuators 722 based on one or more captured eventsand/or instructions or control signals received from a service providerand/or various client systems.

In some implementations, the interface circuitry may connect theplatform 700 with positioning circuitry 745. The positioning circuitry745 includes circuitry to receive and decode signalstransmitted/broadcasted by a positioning network of a GNSS. Examples ofnavigation satellite constellations (or GNSS) include United States'GPS, Russia's GLONASS, the European Union's Galileo system, China'sBeiDou Navigation Satellite System, a regional navigation system or GNSSaugmentation system (e.g., NAVIC), Japan's QZSS, France's DORIS, etc.),or the like. The positioning circuitry 745 comprises various hardwareelements (e.g., including hardware devices such as switches, filters,amplifiers, antenna elements, and the like to facilitate OTAcommunications) to communicate with components of a positioning network,such as navigation satellite constellation nodes. In some embodiments,the positioning circuitry 745 may include a Micro-PNT IC that uses amaster timing clock to perform position tracking/estimation without GNSSassistance. The positioning circuitry 745 may also be part of, orinteract with, the baseband circuitry 710 and/or RFEMs 715 tocommunicate with the nodes and components of the positioning network.The positioning circuitry 745 may also provide position data and/or timedata to the application circuitry 705, which may use the data tosynchronize operations with various infrastructure (e.g., radio basestations), for turn-by-turn navigation applications, or the like

In some implementations, the interface circuitry may connect theplatform 700 with Near-Field Communication (NFC) circuitry 740. NFCcircuitry 740 is configured to provide contactless, short-rangecommunications based on radio frequency identification (RFID) standards,wherein magnetic field induction is used to enable communication betweenNFC circuitry 740 and NFC-enabled devices external to the platform 700(e.g., an “NFC touchpoint”). NFC circuitry 740 comprises an NFCcontroller coupled with an antenna element and a processor coupled withthe NFC controller. The NFC controller may be a chip/IC providing NFCfunctionalities to the NFC circuitry 740 by executing NFC controllerfirmware and an NFC stack. The NFC stack may be executed by theprocessor to control the NFC controller, and the NFC controller firmwaremay be executed by the NFC controller to control the antenna element toemit short-range RF signals. The RF signals may power a passive NFC tag(e.g., a microchip embedded in a sticker or wristband) to transmitstored data to the NFC circuitry 740, or initiate data transfer betweenthe NFC circuitry 740 and another active NFC device (e.g., a smartphoneor an NFC-enabled POS terminal) that is proximate to the platform 700.

The driver circuitry 746 may include software and hardware elements thatoperate to control particular devices that are embedded in the platform700, attached to the platform 700, or otherwise communicatively coupledwith the platform 700. The driver circuitry 746 may include individualdrivers allowing other components of the platform 700 to interact withor control various I/O devices that may be present within, or connectedto, the platform 700. For example, driver circuitry 746 may include adisplay driver to control and allow access to a display device, atouchscreen driver to control and allow access to a touchscreeninterface of the platform 700, sensor drivers to obtain sensor readingsof sensor circuitry 721 and control and allow access to sensor circuitry721, actuator drivers to obtain actuator positions of the actuators 722and/or control and allow access to the actuators 722, a camera driver tocontrol and allow access to an embedded image capture device, audiodrivers to control and allow access to one or more audio devices.

The power management integrated circuitry (PMIC) 725 (also referred toas “power management circuitry 725”) may manage power provided tovarious components of the platform 700. In particular, with respect tothe baseband circuitry 710, the PMIC 725 may control power-sourceselection, voltage scaling, battery charging, or DC-to-DC conversion.The PMIC 725 may often be included when the platform 700 is capable ofbeing powered by a battery 730, for example, when the device is includedin a UE 101.

In some embodiments, the PMIC 725 may control, or otherwise be part of,various power saving mechanisms of the platform 700. For example, if theplatform 700 is in an RRC_Connected state, where it is still connectedto the RAN node as it expects to receive traffic shortly, then it mayenter a state known as DRX after a period of inactivity. During thisstate, the platform 700 may power down for brief intervals of time andthus save power. If there is no data traffic activity for an extendedperiod of time, then the platform 700 may transition off to an RRC Idlestate, where it disconnects from the network and does not performoperations such as channel quality feedback, handover, etc. The platform700 goes into a very low power state and it performs paging where againit periodically wakes up to listen to the network and then powers downagain. The platform 700 may not receive data in this state; in order toreceive data, it must transition back to RRC_Connected state. Anadditional power saving mode may allow a device to be unavailable to thenetwork for periods longer than a paging interval (ranging from secondsto a few hours). During this time, the device is totally unreachable tothe network and may power down completely. Any data sent during thistime incurs a large delay and it is assumed the delay is acceptable.

A battery 730 may power the platform 700, although in some examples theplatform 700 may be mounted deployed in a fixed location, and may have apower supply coupled to an electrical grid. The battery 730 may be alithium ion battery, a metal-air battery, such as a zinc-air battery, analuminum-air battery, a lithium-air battery, and the like. In someimplementations, such as in V2X applications, the battery 730 may be atypical lead-acid automotive battery.

In some implementations, the battery 730 may be a “smart battery,” whichincludes or is coupled with a Battery Management System (BMS) or batterymonitoring integrated circuitry. The BMS may be included in the platform700 to track the state of charge (SoCh) of the battery 730. The BMS maybe used to monitor other parameters of the battery 730 to providefailure predictions, such as the state of health (SoH) and the state offunction (SoF) of the battery 730. The BMS may communicate theinformation of the battery 730 to the application circuitry 705 or othercomponents of the platform 700. The BMS may also include ananalog-to-digital (ADC) convertor that allows the application circuitry705 to directly monitor the voltage of the battery 730 or the currentflow from the battery 730. The battery parameters may be used todetermine actions that the platform 700 may perform, such astransmission frequency, network operation, sensing frequency, and thelike.

A power block, or other power supply coupled to an electrical grid maybe coupled with the BMS to charge the battery 730. In some examples, thepower block XS30 may be replaced with a wireless power receiver toobtain the power wirelessly, for example, through a loop antenna in thecomputer platform 700. In these examples, a wireless battery chargingcircuit may be included in the BMS. The specific charging circuitschosen may depend on the size of the battery 730, and thus, the currentrequired. The charging may be performed using the Airfuel standardpromulgated by the Airfuel Alliance, the Qi wireless charging standardpromulgated by the Wireless Power Consortium, or the Rezence chargingstandard promulgated by the Alliance for Wireless Power, among others.

User interface circuitry 750 includes various I/O devices presentwithin, or connected to, the platform 700, and includes one or more userinterfaces designed to enable user interaction with the platform 700and/or peripheral component interfaces designed to enable peripheralcomponent interaction with the platform 700. The user interfacecircuitry 750 includes input device circuitry and output devicecircuitry. Input device circuitry includes any physical or virtual meansfor accepting an input including, inter alia, one or more physical orvirtual buttons (e.g., a reset button), a physical keyboard, keypad,mouse, touchpad, touchscreen, microphones, scanner, headset, and/or thelike. The output device circuitry includes any physical or virtual meansfor showing information or otherwise conveying information, such assensor readings, actuator position(s), or other like information. Outputdevice circuitry may include any number and/or combinations of audio orvisual display, including, inter alia, one or more simple visualoutputs/indicators (e.g., binary status indicators (e.g., light emittingdiodes (LEDs)) and multi-character visual outputs, or more complexoutputs such as display devices or touchscreens (e.g., Liquid ChrystalDisplays (LCD), LED displays, quantum dot displays, projectors, etc.),with the output of characters, graphics, multimedia objects, and thelike being generated or produced from the operation of the platform 700.The output device circuitry may also include speakers or other audioemitting devices, printer(s), and/or the like. In some embodiments, thesensor circuitry 721 may be used as the input device circuitry (e.g., animage capture device, motion capture device, or the like) and one ormore actuators 722 may be used as the output device circuitry (e.g., anactuator to provide haptic feedback or the like). In another example,NFC circuitry comprising an NFC controller coupled with an antennaelement and a processing device may be included to read electronic tagsand/or connect with another NFC-enabled device. Peripheral componentinterfaces may include, but are not limited to, a non-volatile memoryport, a USB port, an audio jack, a power supply interface, etc.

The components shown by FIG. 7 communicate with one another usinginterface circuitry, which may include IX 706. The IX 706 may includeany number of bus and/or IX technologies such as ISA, EISA, I²C, SPI,point-to-point interfaces, PMBus, PCI) PCIe, Intel® UPI, IAL, CAPI,Intel® QPI, UPI, Intel® OPA IX, RapidIO™ system IXs, CCIA, Gen-ZConsortium IXs, OpenCAPI IX, a HyperTransport interconnect, Time-TriggerProtocol (TTP) system, a FlexRay system, and/or any number of other IXtechnologies. The IX technology may be a proprietary bus, for example,used in an SoC based system.

According to various embodiments, the various components of the system700 may implement an MTSI client in terminal using 3GPP access. The MTSIclient in terminal may include speech decoder and/or encoder circuitry,video decoder and/or encoder circuitry, text decoder and/or encodercircuitry, session setup and control circuitry, and a packet-basednetwork interface. The packet-based network interface handles thetransport of media, which includes the encapsulation of the coded mediain a transport protocol as well as handling of coded media received fromthe network. The packet-based network interface interfaces with 3GPP L2for the transport of media and control data. The various decoder and/orencoder circuitries interface with the user interface circuitry 750 toobtain media data to be encoded for transmission, and to provide decodedmedia data to the user interface circuitry 750 to be output. The variousdecoder and/or encoder circuitries interface with the packet-basednetwork interface to obtain respective encoded media data to be decoded.General control-related elements of an MTSI client for conversationalmedia, such as SIP signaling, are handled by the session setup handlingand session control circuitry. These control-related elements include,for example, usage of SDP (see e.g., RFC 4566) and SDPCapNeg in SIPinvitations for capability negotiation and media stream setup, set-upand control of the individual media streams between clients, andinteractivity such as adding and dropping of media components.

Various combinations of the components of the system 700 may implementthe elements of the MTSI client in terminal. In one example, all of theMTSI client in terminal elements may be implemented in the basebandcircuitry 710. In a second example, the application circuitry 705 mayimplement the speech decoder and/or encoder circuitry, video decoderand/or encoder circuitry, text decoder and/or encoder circuitry, and thesession setup and control circuitry; and the packet-based networkinterface may be implemented by the baseband circuitry 710.

The Multimedia Telephony Service for IMS supports simultaneous transferof multiple media components with real-time characteristics. Mediacomponents denote the actual components that the end-user experiences.Multiple media components (including media components of the same mediatype) may be present in a session, where at least one of thesecomponents is present in all conversational multimedia telephonysessions. All media components can be added or dropped during an ongoingsession as required either by the end-user or by controlling nodes inthe network, assuming that when adding components, the capabilities ofthe MTSI client support the additional component. The media componentsmay include core media components including, for example, speech (e.g.,the sound that is picked up by a microphone of a first terminal (e.g.,UE 101 a), transferred from the first terminal to a second terminal(e.g., UE 101 b), and played out in an earphone/loudspeaker of thesecond terminal; speech includes detection, transport and generation ofDTMF events), video (e.g., moving image(s) captured by a camera of afirst terminal (e.g., UE 101 a), transmitted to a second terminal (e.g.,UE 101 b), and rendered on a display of the second terminal), and text(e.g., characters typed on a keyboard or drawn on a screen on a firstterminal (e.g., UE 101 a) and rendered in real time on the display of asecond terminal (e.g., UE 101 b); the flow is time-sampled so that nospecific action is needed from the user to request transmission). Forthe purposes of the present disclosure, the terms “voice,” “speech,” and“audio” may be synonymous and used interchangeably. The aforementionedmedia components may be transported in real time over RTP with eachrespective payload format mapped onto one or more RTP streams (see e.g.,IETF RFC 3550). Other media types than those mentioned previously may beincluded in a session, for example, facsimile (fax) transmission dataand non-conversational media such as IMS messaging (see e.g., 3GPP TS24.247).

The MTSI client specifies various media codecs for individual mediacomponents. A “codec” refers to program code or process/procedure forencoding or decoding a digital data stream or signal. Examples of thecodecs that may be used include AMR (see e.g., 3GPP TS 26.071) includingAMR-NB, AMR-WB, and EVS AMR-WB IO (i.e., AMR-WB IO included in the EVScodec); EVS; DSR Extended Advanced Front-end codec; DTMF codecs; H.224;H.281; H.263; H.264 (MPEG-4/AVC); H.265 (HEVC); H.324 and/or 3G-324M;EVRC including EVRC-WB; G.729-based codecs including CS-ACELP codecs,the G.729.1 Audio Codec; ITU-T Recommendation T.140 codecs (includingpresentation control functions from ISO 6429); and/or other like codecs.

In various embodiments, the application circuitry 705 and/or thebaseband circuitry 710 may implement JBM circuitry. JBM denotes theactual buffer as well as any control, adaptation and media processingalgorithm (excluding speech decoder) used in the management of thejitter induced in a transport channel. In some implementations, the JBMcircuitry of an MTSI client with an adaptive jitter buffer may include ajitter buffer, network analyzer, adaption control logic, a decoder, andan adaptation unit. The network analyzer and the adaptation controllogic, together with the information on buffer status form the actualbuffer, control the JBM functionality, whereas the decoder and theadaptation unit provide the media processing functionality.

In these implementations, the jitter buffer is configured to unpackincoming RTP payloads and to store received media frames (e.g., speechor video). The buffer status may be used as input to the adaptationcontrol logic. Furthermore, the buffer is also linked to the decoder toprovide frames for decoding when requested for decoding by the decoder.The decoder may be the same or similar to the decoder circuitrymentioned previously. For example, the decoder may be a speech decoderimplementing standard AMR, AMR-WB, and/or EVS speech codecs. In someimplementations, the decoder may include error concealment and/or badframe handling functionality. The decoder may be used with or withoutthe adaptation unit. The network analyzer is configured to monitor theincoming packet stream and to collect reception statistics (e.g.,jitter, packet loss) that are needed for jitter buffer adaptation. Inimplementations where RTCP is used, the network analyzer is alsoconfigured to maintain statistics required by the RTCP.

The adaptation control logic (also referred to as “buffer controllogic”) is configured to adjust playback delay, and the operation of theadaptation functionality makes decisions on the buffering delayadjustments and required media adaptation actions based on the bufferstatus (e.g., average buffering delay, buffer occupancy, etc.) and inputfrom the network analyzer. External control input, including RTCPinputs/statistics from the sender, can be used, for example, to enableinter-media synchronization, to adapt the jitter buffer, and/or otherexternal scaling requests. In these cases, the adaptation control logicprovides scaling requests and scaling window information to theadaptation unit. The adaptation control logic may utilize differentadaptation strategies such as fixed jitter buffer (without adaptationand time scaling), simple adaptation during comfort noise periods orbuffer adaptation also during active speech. The general operation iscontrolled with desired proportion of frames arriving late, adaptationstrategy and adaptation rate.

The adaptation unit is configured to shorten or extend the output signallength according to requests given by the adaptation control logic toenable buffer delay adjustment in a transparent manner. The adaptationis performed using the frame based or sample based time scaling on thedecoder output signal during comfort noise periods only or during activespeech and comfort noise. The buffer control logic may have a mechanismto limit the maximum scaling ratio. Providing a scaling window in whichthe targeted time scale modifications are performed improves thesituation in certain scenarios (e.g., when reacting to the clock driftor to a request of inter-media (re)synchronization) by allowingflexibility in allocating the scaling request on several frames andperforming the scaling on a content-aware manner. The adaptation unitmay be implemented either in a separate entity from the decoder orembedded within the decoder.

Speech JBM used in MTSI may support source-controlled rate operation aswell as non-source-controlled rate operation; is capable to receive thede-packetized frames out of order and present them in order for decoderconsumption; is capable to receive duplicate speech frames and onlypresent unique speech frames for decoder consumption; and is capable ofhandling clock drift between the encoding and decoding end-points. JBMmay also be used for video frames/data wherein the overall design of thebuffer may aim to minimize delay, maintain synchronization with speech,and minimize dropping of late packets. In some implementations, JBM fortext may not be needed, but may still be used according to section 5 ofRFC 4103 where a calculation is described for the time allowed before anextra delayed text packet may be regarded to be lost.

FIG. 8 illustrates components, according to some example embodiments,able to read instructions from a machine-readable or computer-readablemedium (e.g., a non-transitory machine-readable storage medium) andperform any one or more of the methodologies discussed herein. Hardwareresources 800 include one or more processors (or processor cores) 810,one or more memory/storage devices 820, and one or more communicationresources 830, each of which may be communicatively coupled via a bus840. For embodiments where node virtualization (e.g., NFV) is utilized,a hypervisor 802 may be executed to provide an execution environment forone or more network slices/sub-slices to utilize the hardware resources800.

The processors 810 may include, for example, a processor 812 and aprocessor 814. The processor(s) 810 may be, for example, a CPU, areduced instruction set computing (RISC) processor, a CISC processor, aGPU, a DSP such as a baseband processor, an ASIC, an FPGA, a RFIC,another processor (including those discussed herein), or any suitablecombination thereof. The memory/storage devices 820 may include mainmemory, disk storage, or any suitable combination thereof. Thememory/storage devices 820 may include, but are not limited to, any typeof volatile or nonvolatile memory such as DRAM, SRAM, EPROM, EEPROM,Flash memory, solid-state storage, etc.

The communication resources 830 may include interconnection or networkinterface components or other suitable devices to communicate with oneor more peripheral devices 804 or one or more databases 806 via anetwork 808. For example, the communication resources 830 may includewired communication components (e.g., for coupling via USB), cellularcommunication components, NFC components, Bluetooth® (or Bluetooth® LowEnergy) components, Wi-Fi® components, and other communicationcomponents, such as those discussed herein.

Instructions 850 may comprise software, a program, an application, anapplet, an app, or other executable code for causing at least any of theprocessors 810 to perform any one or more of the methodologies discussedherein. The instructions 850 may reside, completely or partially, withinat least one of the processors 810 (e.g., within the processor's cachememory), the memory/storage devices 820, or any suitable combinationthereof. Furthermore, any portion of the instructions 850 may betransferred to the hardware resources 800 from any combination of theperipheral devices 804 or the databases 806. Accordingly, the memory ofprocessors 810, the memory/storage devices 820, the peripheral devices804, and the databases 806 are examples of computer-readable andmachine-readable media.

FIG. 9 illustrates example components of baseband circuitry 910 and RFEM915 in accordance with various embodiments. The baseband circuitry 910corresponds to the baseband circuitry 610 and 710 of FIGS. 6 and 7,respectively. The RFEM 915 corresponds to the RFEM 615 and 715 of FIGS.6 and 7, respectively. As shown, the RFEMs 915 may include RF circuitry906, front-end module (FEM) circuitry 908, antenna array 911 coupledtogether at least as shown.

The baseband circuitry 910 includes circuitry and/or control logicconfigured to carry out various radio/network protocol and radio controlfunctions that enable communication with one or more radio networks viathe RF circuitry 906. The radio control functions may include, but arenot limited to, signal modulation/demodulation, encoding/decoding, radiofrequency shifting, etc. In some embodiments, modulation/demodulationcircuitry of the baseband circuitry 910 may include Fast-FourierTransform (FFT), precoding, or constellation mapping/demappingfunctionality. In some embodiments, encoding/decoding circuitry of thebaseband circuitry 910 may include convolution, tail-biting convolution,turbo, Viterbi, LDPC, and/or polar code encoder/decoder functionality.Embodiments of modulation/demodulation and encoder/decoder functionalityare not limited to these examples and may include other suitablefunctionality in other embodiments. The baseband circuitry 910 isconfigured to process baseband signals received from a receive signalpath of the RF circuitry 906 and to generate baseband signals for atransmit signal path of the RF circuitry 906. The baseband circuitry 910is configured to interface with application circuitry 605/705 (see FIGS.6 and 7) for generation and processing of the baseband signals and forcontrolling operations of the RF circuitry 906. The baseband circuitry910 may handle various radio control functions.

The aforementioned circuitry and/or control logic of the basebandcircuitry 910 may include one or more single or multi-core processors.For example, the one or more processors may include a 3G basebandprocessor 904A, a 4G/LTE baseband processor 904B, a 5G/NR basebandprocessor 904C, or some other baseband processor(s) 904D for otherexisting generations, generations in development or to be developed inthe future (e.g., 6G, etc.). In other embodiments, some or all of thefunctionality of baseband processors 904A-D may be included in modulesstored in the memory 904G and executed via a CPU 904E. In otherembodiments, some or all of the functionality of baseband processors904A-D may be provided as hardware accelerators (e.g., FPGAs, ASICs,etc.) loaded with the appropriate bit streams or logic blocks stored inrespective memory cells. In various embodiments, the memory 904G maystore program code of a real-time OS (RTOS), which when executed by theCPU 904E (or other baseband processor), is to cause the CPU 904E (orother baseband processor) to manage resources of the baseband circuitry910, schedule tasks, etc. Examples of the RTOS may include OperatingSystem Embedded (OSE)™ provided by Enea®, Nucleus RTOS™ provided byMentor Graphics®, Versatile Real-Time Executive (VRTX) provided byMentor Graphics®, ThreadX™ provided by Express Logic®, FreeRTOS, REX OSprovided by Qualcomm®, OKL4 provided by Open Kernel (OK) Labs®, or anyother suitable RTOS, such as those discussed herein. In addition, thebaseband circuitry 910 includes one or more audio DSPs 904F. The audioDSP(s) 904F include elements for compression/decompression and echocancellation and may include other suitable processing elements in otherembodiments.

In some embodiments, each of the processors 904A-904E include respectivememory interfaces to send/receive data to/from the memory 904G. Thebaseband circuitry 910 may further include one or more interfaces tocommunicatively couple to other circuitries/devices, such as aninterface to send/receive data to/from memory external to the basebandcircuitry 910; an application circuitry interface to send/receive datato/from the application circuitry 605/705 of FIGS. 6 and 7); an RFcircuitry interface to send/receive data to/from RF circuitry 906 ofFIG. 9; a wireless hardware connectivity interface to send/receive datato/from one or more wireless hardware elements (e.g., NFC components,Bluetooth®/Bluetooth® Low Energy components, Wi-Fi® components, and/orthe like); and a power management interface to send/receive power orcontrol signals to/from the PMIC 725.

In alternate embodiments (which may be combined with the above describedembodiments), baseband circuitry 910 comprises one or more digitalbaseband systems, which are coupled with one another via an interconnectsubsystem and to a CPU subsystem, an audio subsystem, and an interfacesubsystem. The digital baseband subsystems may also be coupled to adigital baseband interface and a mixed-signal baseband subsystem viaanother interconnect subsystem. Each of the interconnect subsystems mayinclude a bus system, point-to-point connections, network-on-chip (NOC)structures, and/or some other suitable bus or interconnect technology,such as those discussed herein. The audio subsystem may include DSPcircuitry, buffer memory, program memory, speech processing acceleratorcircuitry, data converter circuitry such as analog-to-digital anddigital-to-analog converter circuitry, analog circuitry including one ormore of amplifiers and filters, and/or other like components. In anaspect of the present disclosure, baseband circuitry 910 may includeprotocol processing circuitry with one or more instances of controlcircuitry (not shown) to provide control functions for the digitalbaseband circuitry and/or radio frequency circuitry (e.g., the radiofront end modules 915).

Although not shown by FIG. 9, in some embodiments, the basebandcircuitry 910 includes individual processing device(s) to operate one ormore wireless communication protocols (e.g., a “multi-protocol basebandprocessor” or “protocol processing circuitry”) and individual processingdevice(s) to implement PHY layer functions. In these embodiments, thePHY layer functions include the aforementioned radio control functions.In these embodiments, the protocol processing circuitry operates orimplements various protocol layers/entities of one or more wirelesscommunication protocols. In a first example, the protocol processingcircuitry may operate LTE protocol entities and/or 5G/NR protocolentities when the baseband circuitry 910 and/or RF circuitry 906 arepart of mmWave communication circuitry or some other suitable cellularcommunication circuitry. In the first example, the protocol processingcircuitry would operate MAC, RLC, PDCP, SDAP, RRC, and NAS functions. Ina second example, the protocol processing circuitry may operate one ormore IEEE-based protocols when the baseband circuitry 910 and/or RFcircuitry 906 are part of a Wi-Fi communication system. In the secondexample, the protocol processing circuitry would operate Wi-Fi MAC andLLC functions. The protocol processing circuitry may include one or morememory structures (e.g., 904G) to store program code and data foroperating the protocol functions, as well as one or more processingcores to execute the program code and perform various operations usingthe data. The baseband circuitry 910 may also support radiocommunications for more than one wireless protocol.

The various hardware elements of the baseband circuitry 910 discussedherein may be implemented, for example, as a solder-down substrateincluding one or more integrated circuits (ICs), a single packaged ICsoldered to a main circuit board or a multi-chip module containing twoor more ICs. In one example, the components of the baseband circuitry910 may be suitably combined in a single chip or chipset, or disposed ona same circuit board. In another example, some or all of the constituentcomponents of the baseband circuitry 910 and RF circuitry 906 may beimplemented together such as, for example, a system on a chip (SoC) orSystem-in-Package (SiP). In another example, some or all of theconstituent components of the baseband circuitry 910 may be implementedas a separate SoC that is communicatively coupled with and RF circuitry906 (or multiple instances of RF circuitry 906). In yet another example,some or all of the constituent components of the baseband circuitry 910and the application circuitry 605/705 may be implemented together asindividual SoCs mounted to a same circuit board (e.g., a “multi-chippackage”).

In some embodiments, the baseband circuitry 910 may provide forcommunication compatible with one or more radio technologies. Forexample, in some embodiments, the baseband circuitry 910 may supportcommunication with an E-UTRAN or other WMAN, a WLAN, a WPAN. Embodimentsin which the baseband circuitry 910 is configured to support radiocommunications of more than one wireless protocol may be referred to asmulti-mode baseband circuitry.

RF circuitry 906 may enable communication with wireless networks usingmodulated electromagnetic radiation through a non-solid medium. Invarious embodiments, the RF circuitry 906 may include switches, filters,amplifiers, etc. to facilitate the communication with the wirelessnetwork. RF circuitry 906 may include a receive signal path, which mayinclude circuitry to down-convert RF signals received from the FEMcircuitry 908 and provide baseband signals to the baseband circuitry910. RF circuitry 906 may also include a transmit signal path, which mayinclude circuitry to up-convert baseband signals provided by thebaseband circuitry 910 and provide RF output signals to the FEMcircuitry 908 for transmission.

In some embodiments, the receive signal path of the RF circuitry 906 mayinclude mixer circuitry 906 a, amplifier circuitry 906 b and filtercircuitry 906 c. In some embodiments, the transmit signal path of the RFcircuitry 906 may include filter circuitry 906 c and mixer circuitry 906a. RF circuitry 906 may also include synthesizer circuitry 906 d forsynthesizing a frequency for use by the mixer circuitry 906 a of thereceive signal path and the transmit signal path. In some embodiments,the mixer circuitry 906 a of the receive signal path may be configuredto down-convert RF signals received from the FEM circuitry 908 based onthe synthesized frequency provided by synthesizer circuitry 906 d. Theamplifier circuitry 906 b may be configured to amplify thedown-converted signals and the filter circuitry 906 c may be a low-passfilter (LPF) or band-pass filter (BPF) configured to remove unwantedsignals from the down-converted signals to generate output basebandsignals. Output baseband signals may be provided to the basebandcircuitry 910 for further processing. In some embodiments, the outputbaseband signals may be zero-frequency baseband signals, although thisis not a requirement. In some embodiments, mixer circuitry 906 a of thereceive signal path may comprise passive mixers, although the scope ofthe embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 906 a of the transmit signalpath may be configured to up-convert input baseband signals based on thesynthesized frequency provided by the synthesizer circuitry 906 d togenerate RF output signals for the FEM circuitry 908. The basebandsignals may be provided by the baseband circuitry 910 and may befiltered by filter circuitry 906 c. In some embodiments, the mixercircuitry 906 a of the receive signal path and the mixer circuitry 906 aof the transmit signal path may include two or more mixers and may bearranged for quadrature downconversion and upconversion, respectively.In some embodiments, the mixer circuitry 906 a of the receive signalpath and the mixer circuitry 906 a of the transmit signal path mayinclude two or more mixers and may be arranged for image rejection(e.g., Hartley image rejection). In some embodiments, the mixercircuitry 906 a of the receive signal path and the mixer circuitry 906 aof the transmit signal path may be arranged for direct downconversionand direct upconversion, respectively. In some embodiments, the mixercircuitry 906 a of the receive signal path and the mixer circuitry 906 aof the transmit signal path may be configured for super-heterodyneoperation.

In some embodiments, the output baseband signals and the input basebandsignals may be analog baseband signals, although the scope of theembodiments is not limited in this respect. In some alternateembodiments, the output baseband signals and the input baseband signalsmay be digital baseband signals. In these alternate embodiments, the RFcircuitry 906 may include analog-to-digital converter (ADC) anddigital-to-analog converter (DAC) circuitry and the baseband circuitry910 may include a digital baseband interface to communicate with the RFcircuitry 906.

In some dual-mode embodiments, a separate radio IC circuitry may beprovided for processing signals for each spectrum, although the scope ofthe embodiments is not limited in this respect. In some embodiments, thesynthesizer circuitry 906 d may be a fractional-N synthesizer or afractional N/N+1 synthesizer, although the scope of the embodiments isnot limited in this respect as other types of frequency synthesizers maybe suitable. For example, synthesizer circuitry 906 d may be adelta-sigma synthesizer, a frequency multiplier, or a synthesizercomprising a phase-locked loop with a frequency divider. The synthesizercircuitry 906 d may be configured to synthesize an output frequency foruse by the mixer circuitry 906 a of the RF circuitry 906 based on afrequency input and a divider control input. In some embodiments, thesynthesizer circuitry 906 d may be a fractional NN+1 synthesizer. Insome embodiments, frequency input may be provided by a voltagecontrolled oscillator (VCO), although that is not a requirement. Dividercontrol input may be provided by either the baseband circuitry 910 orthe application circuitry 605/705 depending on the desired outputfrequency. In some embodiments, a divider control input (e.g., N) may bedetermined from a look-up table based on a channel indicated by theapplication circuitry 605/705.

Synthesizer circuitry 906 d of the RF circuitry 906 may include adivider, a delay-locked loop (DLL), a multiplexer and a phaseaccumulator. In some embodiments, the divider may be a dual modulusdivider (DMD) and the phase accumulator may be a digital phaseaccumulator (DPA). In some embodiments, the DMD may be configured todivide the input signal by either N or N+1 (e.g., based on a carry out)to provide a fractional division ratio. In some example embodiments, theDLL may include a set of cascaded, tunable, delay elements, a phasedetector, a charge pump and a D-type flip-flop. In these embodiments,the delay elements may be configured to break a VCO period up into Ndequal packets of phase, where Nd is the number of delay elements in thedelay line. In this way, the DLL provides negative feedback to helpensure that the total delay through the delay line is one VCO cycle. Insome embodiments, synthesizer circuitry 906 d may be configured togenerate a carrier frequency as the output frequency, while in otherembodiments, the output frequency may be a multiple of the carrierfrequency (e.g., twice the carrier frequency, four times the carrierfrequency) and used in conjunction with quadrature generator and dividercircuitry to generate multiple signals at the carrier frequency withmultiple different phases with respect to each other. In someembodiments, the output frequency may be a LO frequency (fLO). In someembodiments, the RF circuitry 906 may include an IQ/polar converter.

FEM circuitry 908 may include a receive signal path, which may includecircuitry configured to operate on RF signals received from antennaarray 911, amplify the received signals and provide the amplifiedversions of the received signals to the RF circuitry 906 for furtherprocessing. FEM circuitry 908 may also include a transmit signal path,which may include circuitry configured to amplify signals fortransmission provided by the RF circuitry 906 for transmission by one ormore of antenna elements of antenna array 911. In various embodiments,the amplification through the transmit or receive signal paths may bedone solely in the RF circuitry 906, solely in the FEM circuitry 908, orin both the RF circuitry 906 and the FEM circuitry 908.

In some embodiments, the FEM circuitry 908 may include a TX/RX switch toswitch between transmit mode and receive mode operation. The FEMcircuitry 908 may include a receive signal path and a transmit signalpath. The receive signal path of the FEM circuitry 908 may include anLNA to amplify received RF signals and provide the amplified received RFsignals as an output (e.g., to the RF circuitry 906). The transmitsignal path of the FEM circuitry 908 may include a power amplifier (PA)to amplify input RF signals (e.g., provided by RF circuitry 906), andone or more filters to generate RF signals for subsequent transmissionby one or more antenna elements of the antenna array 911.

The antenna array 911 comprises one or more antenna elements, each ofwhich is configured convert electrical signals into radio waves totravel through the air and to convert received radio waves intoelectrical signals. For example, digital baseband signals provided bythe baseband circuitry 910 is converted into analog RF signals (e.g.,modulated waveform) that will be amplified and transmitted via theantenna elements of the antenna array 911 including one or more antennaelements (not shown). The antenna elements may be omnidirectional,direction, or a combination thereof. The antenna elements may be formedin a multitude of arranges as are known and/or discussed herein. Theantenna array 911 may comprise microstrip antennas or printed antennasthat are fabricated on the surface of one or more printed circuitboards. The antenna array 911 may be formed in as a patch of metal foil(e.g., a patch antenna) in a variety of shapes, and may be coupled withthe RF circuitry 906 and/or FEM circuitry 908 using metal transmissionlines or the like.

Processors of the application circuitry 605/705 and processors of thebaseband circuitry 910 may be used to execute elements of one or moreinstances of a protocol stack. For example, processors of the basebandcircuitry 910, alone or in combination, may be used execute Layer 3,Layer 2, or Layer 1 functionality, while processors of the applicationcircuitry 605/705 may utilize data (e.g., packet data) received fromthese layers and further execute Layer 4 functionality (e.g., TCP andUDP layers). As referred to herein, Layer 3 may comprise a RRC layer,described in further detail below. As referred to herein, Layer 2 maycomprise a MAC layer, an RLC layer, and a PDCP layer, described infurther detail below. As referred to herein, Layer 1 may comprise a PHYlayer of a UE/RAN node, described in further detail infra.

FIG. 10 illustrates various protocol functions that may be implementedin a wireless communication device according to various embodiments. Inparticular, FIG. 10 includes protocol stack 1000 showinginterconnections between various protocol layers/entities. The followingdescription of FIG. 10 is provided for various protocol layers/entitiesthat operate in conjunction with the 5G/NR system standards and LTEsystem standards, but some or all of the aspects of FIG. 10 may beapplicable to other wireless communication network systems as well. Theprotocol layers of protocol stack 1000 may include one or more of PHY1010, MAC 1020, RLC 1030, PDCP 1040, SDAP 1047, RRC 1055, and NAS 1057,in addition to other higher layer functions not illustrated. Theprotocol layers may include one or more service access points (e.g.,items 1059, 1056, 1050, 1049, 1045, 1035, 1025, and 1015 in FIG. 10)that may provide communication between two or more protocol layers.

The PHY 1010 may transmit and receive physical layer signals 1005 thatmay be received from or transmitted to one or more other communicationdevices. The physical layer signals 1005 may comprise one or morephysical channels, such as those discussed herein. The PHY 1010 mayfurther perform link adaptation or adaptive modulation and coding (AMC),power control, cell search (e.g., for initial synchronization andhandover purposes), and other measurements used by higher layers, suchas the RRC 1055. The PHY 1010 may still further perform error detectionon the transport channels, forward error correction (FEC)coding/decoding of the transport channels, modulation/demodulation ofphysical channels, interleaving, rate matching, mapping onto physicalchannels, and MIMO antenna processing. In embodiments, an instance ofPHY 1010 may process requests from and provide indications to aninstance of MAC 1020 via one or more PHY-SAP 1015. According to someembodiments, requests and indications communicated via PHY-SAP 1015 maycomprise one or more transport channels.

Instance(s) of MAC 1020 may process requests from, and provideindications to, an instance of RLC 1030 via one or more MAC-SAPs 1025.These requests and indications communicated via the MAC-SAP 1025 maycomprise one or more logical channels. The MAC 1020 may perform mappingbetween the logical channels and transport channels, multiplexing of MACSDUs from one or more logical channels onto TBs to be delivered to PHY1010 via the transport channels, de-multiplexing MAC SDUs to one or morelogical channels from TBs delivered from the PHY 1010 via transportchannels, multiplexing MAC SDUs onto TBs, scheduling informationreporting, error correction through HARQ, and logical channelprioritization.

Instance(s) of MAC 1020 may also perform a RAN-assisted codec adaptationor ANBR (also referred to as a “recommended bit rate procedure”). Therecommended bit rate procedure is used to provide the MAC 1020implemented by a UE 101 with information about the bit rate (e.g., forPHY 1010) which the RAN node 111 (e.g., eNB or gNB) recommends. Anaveraging window of default value 2000 ms may apply as specified in 3GPPTS 26.114. The RAN node 111 may transmit the recommended bit rate MAC CE(see e.g., FIG. 11) to the MAC 1020 of the UE 101 to indicate therecommended bit rate for the UE 101 for a specific logical channel and aspecific direction (either uplink or downlink). Upon reception of arecommended bit rate MAC CE, the MAC 1020 may indicate, to upper layers,the recommended bit rate for the indicated logical channel anddirection. The MAC 1020 may request the RAN node 111 to indicate therecommended bit rate for a specific logical channel and a specificdirection. If the MAC 1020 is requested by upper layers to query the RANnode 111 for the recommended bit rate for a logical channel and for adirection (e.g., for uplink or downlink), the MAC 1020 may trigger arecommended bit rate query for the logical channel, direction, anddesired bit rate if/when a recommended bit rate query for the logicalchannel and direction has not been triggered. If the MAC 1020 has ULresources allocated for new transmission the MAC 1020 may, for eachrecommended bit rate query that the recommended bit rate proceduredetermines has been triggered and not cancelled, instruct themultiplexing and assembly entity within the MAC 1020 to generate therecommended bit rate MAC CE for the logical channel and the direction ofthe recommended bit rate query; start the bitRateQueryProhibitTimer forthe logical channel and the direction of the recommended bit rate query;and cancel the recommended bit rate query when thebitRateQueryProhibitTimer for the logical channel and the direction ofthe recommended bit rate query is configured, and it is not running, andwhen the MAC 1020 has UL resources allocated for new transmission andthe allocated UL resources can accommodate a recommended bit rate MAC CEplus its subheader as a result of LCP.

FIG. 11 depicts an example recommended bit rate MAC CE 1100A and anexample recommended bit rate MAC CE 1100B according to variousembodiments. The MAC CE 1100A is used to convey recommended bit ratequeries and recommended bit rate messages in LTE implementations and theMAC CE 1100B is used to convey recommended bit rate queries andrecommended bit rate messages in NR implementations. Recommended bitrate messages are used to indicate the recommended bit rate for the UE101 for a specific logical channel and a specific direction (either ULor DL). Recommended bit rate queries are used to query or otherwiserequest a recommended bit rate for a specific logical channel and aspecific direction from the RAN node 111. Recommended bit rate queriesare also used to indicate a desired bit rate or radio level adaptation.

The recommended bit rate MAC CEs 1100A-B are each identified by a MACPDU subheader with a first LCID value for bit rate recommendationmessage from the RAN node 111 to the UE 101 (e.g., over the DL-SCH) anda second LCID value for a bit rate recommendation query message from theUE 101 to the RAN node 111 (e.g., over an UL-SCH). For LTEimplementations, the first LCID value may be “10110,” and the secondLCID value may be “10100.” For NR implementations, the first LCID valuemay be “47,” and the second LCID value may be “53.” The MAC CEs 1100A-Bmay each have a fixed size and may include two octets. For each MAC CE1100A-B the first octet (oct 1) includes an LCID field, Uplink/Downlink(UL/DL) field, and part of a bit rate field; and the second octet (oct2) includes a remaining portion of the bit rat field and a plurality ofreserved bit (R) fields. The LCID field indicates the identity of thelogical channel for which the recommended bit rate or the recommendedbit rate query is applicable. The length of the LCID field is 4 bits forMAC CE 1100A and the LCID field for MAC CE 1100B is 6 bits. The UL/DLfield indicates whether the recommended bit rate or the recommended bitrate query applies to uplink or downlink. For both MAC CE 1100A and1100B the length of the UL/DL field is 1 bit. For both MAC CE 1100A and1100B the UL/DL field is set to “0” to indicate downlink and set to “1”to indicate uplink. The bit rate field indicates a value of therecommended bit rate for the bit rate recommendation message, andindicates a value of a desired bit rate for the bit rate recommendationquery. For both MAC CE 1100A and 1100B the length of the bit rate fieldis 6 bits. Each of the R fields includes a reserved bit, which is/areset to “0”.

Referring back to FIG. 10, instance(s) of RLC 1030 may process requestsfrom and provide indications to an instance of PDCP 1040 via one or moreradio link control service access points (RLC-SAP) 1035. These requestsand indications communicated via RLC-SAP 1035 may comprise one or moreRLC channels. The RLC 1030 may operate in a plurality of modes ofoperation, including: TM, UM, and AM. The RLC 1030 may execute transferof upper layer protocol data units (PDUs), error correction throughautomatic repeat request (ARQ) for AM data transfers, and concatenation,segmentation and reassembly of RLC SDUs for UM and AM data transfers.The RLC 1030 may also execute re-segmentation of RLC data PDUs for AMdata transfers, reorder RLC data PDUs for UM and AM data transfers,detect duplicate data for UM and AM data transfers, discard RLC SDUs forUM and AM data transfers, detect protocol errors for AM data transfers,and perform RLC re-establishment.

Instance(s) of PDCP 1040 may process requests from and provideindications to instance(s) of RRC 1055 and/or instance(s) of SDAP 1047via one or more packet data convergence protocol service access points(PDCP-SAP) 1045. These requests and indications communicated viaPDCP-SAP 1045 may comprise one or more radio bearers. The PDCP 1040 mayexecute header compression and decompression of IP data, maintain PDCPSequence Numbers (SNs), perform in-sequence delivery of upper layer PDUsat re-establishment of lower layers, eliminate duplicates of lower layerSDUs at re-establishment of lower layers for radio bearers mapped on RLCAM, cipher and decipher control plane data, perform integrity protectionand integrity verification of control plane data, control timer-baseddiscard of data, and perform security operations (e.g., ciphering,deciphering, integrity protection, integrity verification, etc.).

Instance(s) of SDAP 1047 may process requests from and provideindications to one or more higher layer protocol entities via one ormore SDAP-SAP 1049. These requests and indications communicated viaSDAP-SAP 1049 may comprise one or more QoS flows. The SDAP 1047 may mapQoS flows to DRBs, and vice versa, and may also mark QFIs in DL and ULpackets. A single SDAP entity 1047 may be configured for an individualPDU session. In the UL direction, the NG-RAN 110 may control the mappingof QoS Flows to DRB(s) in two different ways, reflective mapping orexplicit mapping. For reflective mapping, the SDAP 1047 of a UE 101 maymonitor the QFIs of the DL packets for each DRB, and may apply the samemapping for packets flowing in the UL direction. For a DRB, the SDAP1047 of the UE 101 may map the UL packets belonging to the QoS flows(s)corresponding to the QoS flow ID(s) and PDU session observed in the DLpackets for that DRB. To enable reflective mapping, the NG-RAN 110 maymark DL packets over the Uu interface with a QoS flow ID. The explicitmapping may involve the RRC 1055 configuring the SDAP 1047 with anexplicit QoS flow to DRB mapping rule, which may be stored and followedby the SDAP 1047. In embodiments, the SDAP 1047 may only be used in NRimplementations and may not be used in LTE implementations.

The RRC 1055 may configure, via one or more management service accesspoints (M-SAP), aspects of one or more protocol layers, which mayinclude one or more instances of PHY 1010, MAC 1020, RLC 1030, PDCP 1040and SDAP 1047. In embodiments, an instance of RRC 1055 may processrequests from and provide indications to one or more NAS entities 1057via one or more RRC-SAPs 1056. The main services and functions of theRRC 1055 may include broadcast of system information (e.g., included inMIBs or SIBs related to the NAS), broadcast of system informationrelated to the access stratum (AS), paging, establishment, maintenanceand release of an RRC connection between the UE 101 and RAN 110 (e.g.,RRC connection paging, RRC connection establishment, RRC connectionmodification, and RRC connection release), establishment, configuration,maintenance and release of point to point Radio Bearers, securityfunctions including key management, inter-RAT mobility, and measurementconfiguration for UE measurement reporting. The MIBs and SIBs maycomprise one or more IEs, which may each comprise individual data fieldsor data structures.

According to various embodiments, RRC 1055 is used to configure the UE101 with specific parameters, and for the UE 101 to provide the networkwith UE-specific parameters. For example, the RRC 1055 of a RAN node 111may transmit a suitable RRC message (e.g., RRC connectionreconfiguration message, RRC setup message during an RRC connectionestablishment procedure, or the like) to the UE 101, where the RRCmessage includes one or more IEs, which is a structural elementcontaining one or more fields where each field includes parameters,content, and/or data. The parameters, content, and/or data included inthe one or more fields of the IEs are used to configure the UE 101 tooperate in a particular manner. Additionally, the UE 101 may send asuitable RRC message to indicate supported radio capabilities, and torequest a change to one or more radio link parameters as discussedherein.

As an example, a UE assistance information (UEAssistanceInformation)message may be used to indicate UE assistance information to thenetwork, such as a RAN 110. The purpose of the UEAssistanceInformationprocedure for LTE implementations is to inform an E-UTRAN 110 of theUE's 101 power saving preference and SPS assistance information, maximumPDSCH/PUSCH bandwidth configuration preference, overheating assistanceinformation, or the UE's 101 delay budget report carrying desiredincrement/decrement in the Uu air interface delay or connected mode DRXcycle length and for BL UEs or UEs in CE of the RLM event(“early-out-of-sync” or “early-in-sync”) and RLM information. Uponconfiguring the UE 101 to provide power preference indications, theE-UTRAN 110 may consider that the UE 101 does not prefer a configurationprimarily optimized for power saving until the UE 101 explicitlyindicates otherwise. Table 4 shows an example LTE-basedUEAssistanceInformation message, and table 5 shows field descriptionsfor the LTE-based UEAssistanceInformation message.

TABLE 4 UEAssistanceInformation message (LTE implementations) --ASN1START UEAssistanceInformation-r11 ::= SEQUENCE { criticalExtensions        CHOICE {   c1               CHOICE {   ueAssistanceInformation-r11     UEAssistanceInformation-r11-IEs,   spare3 NULL, spare2 NULL, spare1 NULL   },  criticalExtensionsFuture       SEQUENCE { }  } }UEAssistanceInformation-r11-IEs ::=  SEQUENCE { powerPrefindication-r11       ENUMERATED {normal, lowPowerConsumption} OPTIONAL,  lateNonCriticalExtension      OCTETSTRING           OPTIONAL, nonCriticalExtension   UEAssistanceInformation-v1430-IEs       OPTIONAL} UEAssistanceInformation-v1430-IEs ::= SEQUENCE { bw-Preference-r14           BW-Preference-r14        OPTIONAL, sps-AssistanceInformation-r14      SEQUENCE {  trafficPatternInfoListSL-r14    TrafficPatternInfoList-r14  OPTIONAL,  trafficPatternInfoListUL-r14   TrafficPatternInfoList-r14  OPTIONAL }     OPTIONAL,  rlm-Report-r14           SEQUENCE {  rlm-Event-r14          ENUMERATED {earlyOutOfSync, earlyInSync},  excessRep-MPDCCH-r14       ENUMERATED {excessRep1, excessRep2} OPTIONAL  }                                    OPTIONAL, delayBudgetReport-r14      DelayBudgetReport-r14          OPTIONAL, nonCriticalExtension       UEAssistanceInformation-v1450-IEs   OPTIONAL} UEAssistanceInformation-v1450-IEs ::= SEQUENCE { overheatingAssistance-r14      OverheatingAssistance-r14      OPTIONAL, nonCriticalExtension        UEAssistanceInformation-v1530-IEs  OPTIONAL} UEAssistanceInformation-v1530-IEs ::= SEQUENCE { sps-AssistanceInformation-v1530     SEQUENCE {  trafficPatternInfoListSL-v1530     TrafficPatternInfoList-v1530 }   OPTIONAL,  nonCriticalExtension         SEQUENCE {}          OPTIONAL } BW-Preference-r14 ::= SEQUENCE { dl-Preference-r14   ENUMERATED {mhz1dot4, mhz5, mhz20 }     OPTIONAL, ul-Preference-r14   ENUMERATED {mhz1dot4, mhz5}         OPTIONAL }TrafficPatternInfoList-r14 ::= SEQUENCE (SIZE(1..maxTrafficPattern-r14)) OF TrafficPatternInfo-r14TrafficPatternInfo-r14 ::= SEQUENCE { trafficPeriodicity-r14     ENUMERATED {                 sf20, sf50,sf100, sf200, sf300, sf400, sf500,                 sf600, sf700, sf800,sf900, sf1000},  timingOffset-r14       INTEGER (0..10239), priorityInfoSL-r14       SL-Priority-r13             OPTIONAL, logicalChannelIdentityUL-r14  INTEGER (3..10)             OPTIONAL, messageSize-r14        BIT STRING (SIZE (6)) }TrafficPatternInfoList-v1530 ::=SEQUENCE (SIZE(1..maxTrafficPattern-r14)) OF TrafficPatternInfo-v1530TrafficPatternInfo-v1530 ::=SEQUENCE { trafficDestination-r15    SL-DestinationIdentity-r12         OPTIONAL, reliabilityInfoSL-r15  SL-Reliability-r15               OPTIONAL }DelayBudgetReport-r14::= CHOICE {  type1         ENUMERATED {              msMinus1280, msMinus640, msMinus320, msMinus160,              msMinus80, msMinus60, msMinus40, msMinus20, ms0,ms20,                 ms40, ms60, ms80, ms160, ms320, ms640, ms1280}, type2         ENUMERATED {               msMinus192,msMinus168,msMinus144, msMinus120,               msMinus96, msMinus72,msMinus48, msMinus24, ms0, ms24,                 ms48, ms72, ms96,ms120, ms144, ms168, ms192} } OverheatingAssistance-r14 ::= SEQUENCE }  reducedUE-Category      SEQUENCE }   reducedUE-CategoryDL      INTEGER (0..19),   reducedUE-CategoryUL      INTEGER (0..21)   }  OPTIONAL,  reducedMaxCCs        SEQUENCE }    reducedCCsDL          INTEGER(0..31),    reducedCCsUL          INTEGER (0..31)   }  OPTIONAL } --ASN1STOP

TABLE 5 UEAssistanceInformation field descriptions (LTE implementations)UEAssistanceInformation field descriptions delayBudgetReport Indicatesthe UE-preferred adjustment to connected mode DRX or coverageenhancement configuration. dl-Preference Indicates UE's preference onconfiguration of maximum PDSCH bandwidth. The value mhz1dot4 correspondsto CE mode usage in 1.4MHz bandwidth, mhz5 corresponds to CE mode usagein 5MHz bandwidth, and mhz20 corresponds to CE mode usage in 20MHzbandwidth or normal coverage. excessRep-MPDCCH Indicates the excessnumber of repetitions on MPDCCH. Value excessRep1 and excessRep2indicate the excess number of repetitions defined in TS 36.133.logicalChannelldentityUL Indicates the logical channel identityassociated with the reported traffic pattern in the uplink logicalchannel. messageSize Indicates the maximum TB size based on the observedtraffic pattern. The value refers to the index of TS 36.321, table6.1.3.1-1. powerPrefIndication Value lowPowerConsumption indicates theUE prefers a configuration that is primarily optimised for power saving.Otherwise the value is set to normal. prioritylnfoSL Indicates thetraffic priority (i.e., PPPP) associated with the reported trafficpattern for V2X SL communication. reducedCCsDL Indicates the UE'spreference on reduced configuration corresponding to the maximum numberof downlink SCells indicated by the field, to address overheating. Thismaximum number includes both SCells of E-UTRA and PSCell/SCells of NR inEN-DC. reducedCCsUL Indicates the UE's preference on reducedconfiguration corresponding to the maximum number of uplink SCellsindicated by the field, to address overheating. This maximum numberincludes both SCells of E-UTRA and PSCell/SCells of NR in EN-DC.reducedUE-CategoryDL, reducedUE-CategoryUL Indicates that UE prefers aconfiguration corresponding to the reduced UE category, to addressoverheating. The reduced UE DL category and reduced UE UL categoryshould be indicated according to supported combinations for UE UL and DLCategories, see TS 36.306, TABLE 4.1A-6. reliabilityInfoSL Indicates thetraffic reliability (i.e., PPPR) associated with the reported trafficpattern for V2X SL communication. rim-Event This field provides the RLMevent (“early-out-of-sync” or “early-in-sync”). rim-Report This fieldprovides the RLM report for BL UEs and UEs in CE.sps-AssistanceInformation Indicates the UE assistance information toassist E-UTRAN to configure SPS. timingOffset This field indicates theestimated timing for a packet arrival in a SL/UL logical channel.Specifically, the value indicates the timing offset with respect tosubframe#0 of SFN#0 in milliseconds. trafficDestination Indicates thedestination associated with the reported traffic pattern for V2X SLcommunication. trafficPatternInfoListSL This field provides the trafficcharacteristics of SL logical channel(s) that are setup for V2X SLcommunication. If trafficPattemInfoListSL-v1530 is included, it includesthe same number of entries, and listed in the same order, as intrafficPattemInfoListSL-r14. trafficPatternInfoListUL This fieldprovides the traffic characteristics of uplink logical channel(s).trafficPeriodicity This field indicates the estimated data arrivalperiodicity in a SL/UL logical channel. Value sf20 corresponds to 20 ms,sf50 corresponds to 50 ms and so on. type1 Indicates the preferredamount of increment/decrement to the connected mode DRX cycle lengthwith respect to the current configuration. Value in number ofmilliseconds. Value ms40 corresponds to 40 milliseconds, msMinus40corresponds to −40 milliseconds and so on. type2 Indicates the preferredamount of increment/decrement to the coverage enhancement configurationwith respect to the current configuration so that the Uu air interfacedelay changes by the indicated amount. Value in number of milliseconds.Value ms24 corresponds to 24 milliseconds, msMinus24 corresponds to −24milliseconds and so on. ul-Preference Indicates UE's preference onconfiguration of maximum PUSCH bandwidth. The value mhz1dot4 correspondsto CE mode usage in 1.4MHz bandwidth, and mhz5 corresponds to CE modeusage in 5MHz bandwidth.

When the UE 101 is capable of providing power preference indications inRRC_CONNECTED, the UE 101 may initiate the UEAssistanceInformationprocedure in several cases including upon being configured to providepower preference indications and upon change of power preference. Whenthe UE 101 is capable of providing SPS assistance information inRRC_CONNECTED, the UE 101 may initiate the UEAssistanceInformationprocedure in several cases including upon being configured to provideSPS assistance information and upon change of SPS assistanceinformation. When the UE 101 is capable of providing delay budget reportin RRC_CONNECTED, the UE 101 may initiate the UEAssistanceInformationprocedure in several cases, including upon being configured to providedelay budget report and upon change of delay budget preference. When theUE 101 is capable of CE mode and providing maximum PDSCH/PUSCH bandwidthpreference in RRC_CONNECTED, the UE 101 may initiate theUEAssistanceInformation procedure upon being configured to providemaximum PDSCH/PUSCH bandwidth preference and/or upon change of maximumPDSCH/PUSCH bandwidth preference. When the UE 101 is capable ofproviding overheating assistance information in RRC_CONNECTED, the UE101 may initiate the UEAssistanceInformation procedure if it wasconfigured to do so, upon detecting internal overheating, or upondetecting that it is no longer experiencing an overheating condition. InLTE implementations, the UEAssistanceInformation message may be includedin an UL-DCCH-Message. The UL-DCCH-Message class is the set of RRCmessages that may be sent from the UE to the E-UTRAN or from the RN tothe E-UTRAN on the uplink DCCH logical channel. An example LTE-basedUL-DCCH-Message is shown by table 6.

TABLE 6 UL-DCCH-Message (LTE implementations) -- ASN1STARTUL-DCCH-Message ::= SEQUENCE {  message   UL-DCCH-MessageType }UL-DCCH-MessageType ::= CHOICE {  c1     CHOICE {  csfbParametersRequestCDMA2000  CSFBParametersRequestCDMA2000,  measurementReport  MeasurementReport,  rrcConnectionReconfigurationCompleteRRCConnectionReconfigurationComplete,  rrcConnectionReestablishmentCompleteRRCConnectionReestablishmentComplete,   rrcConnectionSetupComplete RRCConnectionSetupComplete,   securityModeComplete SecurityModeComplete,   securityModeFailure  SecurityModeFailure,  ueCapabilityInformation  UECapabilityInformation,  ulHandoverPreparationTransfer ULHandoverPreparationTransfer,  ulInformationTransfer ULInformationTransfer,   counterCheckResponseCounterCheckResponse,   ueInformationResponse-r9UEInformationResponse-r9,   proximityIndication-r9ProximityIndication-r9,   rnReconfigurationComplete-r10RNReconfigurationComplete-r10,   mbmsCountingResponse-r10 MBMSCountingResponse-r10,   interFreqRSTDMeasurementIndication-r10 InterFreqRSTDMeasurementIndication-r10  },  messageClassExtensionCHOICE{   c2 CHOICE {    ueAssistanceInformation-r11 UEAssistanceInformation-r11,    inDeviceCoexIndication-r11InDeviceCoexIndication-r11,    mbmsInterestIndication-r11MBMSInterestIndication-r11,    scgFailureInformation-r12SCGFailureInformation-r12,    sidelinkUEInformation-r12SidelinkUEInformation-r12,    wlanConnectionStatusReport-r13WLANConnectionStatusReport-r13,    rrcConnectionResumeComplete-r13 RRCConnectionResumeComplete-r13,    ulInformationTransferMRDC-r15 ULInformationTransferMRDC-r15,    scgFailureInformationNR-r15 SCGFailureInformationNR-r15,    measReportAppLayer-r15 MeasReportAppLayer-r15,    failureInformation-r15FailureInformation-r15,    spare5 NULL, spare4 NULL, spare3 NULL, spare2NULL, spare1 NULL   },   messageClassExtensionFuture-r11  SEQUENCE { } } } -- ASN1STOP

The purpose of the UEAssistanceInformation procedure for NRimplementations is to inform the network of the UE's 101/101 delaybudget report carrying desired increment/decrement in the Uu airinterface delay, connected mode DRX cycle length or overheatingassistance information. Table 7 shows an example NR-basedUEAssistanceInformation message, and table 8 shows field descriptionsfor the NR-based UEAssistanceInformation message.

TABLE 7 UEAssistanceInformation message (NR implementations) --ASN1START -- TAG-UEASSISTANCEINFORMATION-START UEAssistanceInformation::=  SEQUENCE {  criticalExtensions  CHOICE {   ueAssistanceInformation UEAssistanceInformation-IEs,   criticalExtensionsFuture SEQUENCE { }  }} UEAssistanceInformation-IEs ::= SEQUENCE { delayBudgetReport  DelayBudgetReport  OPTIONAL, lateNonCriticalExtension OCTET STRING   OPTIONAL, nonCriticalExtension   UEAssistanceInformation-v1540-IEs OPTIONAL }DelayBudgetReport::=   CHOICE {  type1   ENUMERAIED I      msMinus1280,msMinus640, msMinus320, msMinus160,msMinus80, msMinus60, msMinus40,     msMinus20, ms0, ms20,ms40, ms60, ms80, ms160, ms320, ms640,ms1280},  . . . } UEAssistanceInformation-v1540-IEs ::= SEQUENCE { overheatingAssistance   OverheatingAssistance  OPTIONAL, nonCriticalExtension  SEQUENCE { }    OPTIONAL } OverheatingAssistance::=  SEQUENCE {  reducedMaxCCs SEQUENCE {   reducedCCsDL INTEGER(0..31),   reducedCCsUL INTEGER (0..31)  } OPTIONAL,  reducedMaxBW-FR1SEQUENCE {   reducedBW-FR1-DL ReducedAggregatedBandwidth,  reducedBW-FR1-UL ReducedAggregatedBandwidth  } OPTIONAL, reducedMaxBW-FR2 SEQUENCE {   reducedBW-FR2-DLReducedAggregatedBandwidth,   reducedBW-FR2-ULReducedAggregatedBandwidth  } OPTIONAL,  reducedMaxMIMO-LayersFR1SEQUENCE {   reducedMIMO-LayersFR1-DL MIMO-LayersDL,  reducedMIMO-LayersFR1-UL MIMO-LayersUL  } OPTIONAL, reducedMaxMIMO-LayersFR2 SEQUENCE I   reducedMIMO-LayersFR2-DLMIMO-LayersDL,   reducedMIMO-LayersFR2-UL MIMO-LayersUL  } OPTIONAL }ReducedAggregatedBandwidth ::= ENUMERATED {mhz0, mhz10, mhz20, mhz30,mhz40, mhz50, mhz60, mhz80, mhz100, mhz200, mhz300, mhz400} --TAG-UEASSISTANCEINFORMATION-STOP -- ASN1STOP

TABLE 8 UEAssistanceInformation field descriptions (NR implementations)UEAssistanceInformation field descriptions delayBudgetReport Indicatesthe UE-preferred adjustment to connected mode DRX. reducedBW-FR1-DLIndicates the UE's preference on reduced configuration corresponding tothe maximum aggregated bandwidth across all downlink carriers of FR1indicated by the field, to address overheating. This field is allowed tobe reported only when UE is configured with serving cells operating onFR1. reducedBW-FR1-UL Indicates the UE's preference on reducedconfiguration corresponding to the maximum aggregated bandwidth acrossall uplink carriers of FR1 indicated by the field, to addressoverheating. This field is allowed to be reported only when UE isconfigured with serving cells operating on FR1. reducedBW-FR2-DLIndicates the UE's preference on reduced configuration corresponding tothe maximum aggregated bandwidth across all downlink carriers of FR2indicated by the field, to address overheating. This field is allowed tobe reported only when UE is configured with serving cells operating onFR2. mhz0 is only applicable for FR2. reducedBW-FR2-UL Indicates theUE's preference on reduced configuration corresponding to the maximumaggregated bandwidth across all uplink carriers of FR2 indicated by thefield, to address overheating. This field is allowed to be reported onlywhen UE is configured with serving cells operating on FR2. mhz0 is onlyapplicable for FR2. reducedCCsDL Indicates the UE's preference onreduced configuration corresponding to the maximum number of downlinkSCells indicated by the field, to address overheating. reducedCCsULIndicates the UE's preference on reduced configuration corresponding tothe maximum number of uplink SCells indicated by the field, to addressoverheating. reducedMIMO-LayersFR1-DL Indicates the UE's preference onreduced configuration corresponding to the maximum number of downlinkMIMO layers of each serving cell operating on FR1 indicated by thefield, to address overheating. This field is allowed to be reported onlywhen UE is configured with serving cells operating on FR1.reducedMIMO-LayersFR1-UL Indicates the UE's preference on reducedconfiguration corresponding to the maximum number of uplink MIMO layersof each serving cell operating on FR1 indicated by the field, to addressoverheating. This field is allowed to be reported only when UE isconfigured with serving cells operating on FR1. reducedMIMO-LayersFR2-DLIndicates the UE's preference on reduced configuration corresponding tothe maximum number of downlink MIMO layers of each serving celloperating on FR2 indicated by the field, to address overheating. Thisfield is allowed to be reported only when UE is configured with servingcells operating on FR2. reducedMIMO-LayersFR2-UL Indicates the UE'spreference on reduced configuration corresponding to the maximum numberof uplink MIMO layers of each serving cell operating on FR2 indicated bythe field, to address overheating. This field is allowed to be reportedonly when UE is configured with serving cells operating on FR2. type1Indicates the preferred amount of increment/decrement to the long DRXcycle length with respect to the current configuration. Value in numberof milliseconds. Value ms40 corresponds to 40 milliseconds, msMinus40corresponds to −40 milliseconds and so on.

When the UE 101/101 is capable of providing delay budget report inRRC_CONNECTED, the UE 101/101 may initiate the UEAssistanceInformationprocedure in several cases, including upon being configured to providedelay budget report and upon change of delay budget preference. When theUE 101/101 is capable of providing overheating assistance information inRRC_CONNECTED, the UE 101/101 may initiate the UEAssistanceInformationprocedure if the UE 101/101 was configured to do so, upon detectinginternal overheating, or upon detecting that it is no longerexperiencing an overheating condition. In NR implementations, theUEAssistanceInformation message may be included in an UL-DCCH-Message.The UL-DCCH-Message class is the set of RRC messages that may be sentfrom the UE to the network on the uplink DCCH logical channel. Anexample NR-based UL-DCCH-Message is shown by table 9.

TABLE 9 UL-DCCH-Message -- ASN1START -- TAG-UL-DCCH-MESSAGE-STARTUL-DCCH-Message ::=  SEQUENCE {  message   UL-DCCH-MessageType }UL-DCCH-MessageType ::=  CHOICE {  c1   CHOICE {  measurementReport  MeasurementReport,  rrcReconfigurationComplete RRCReconfigurationComplete,  rrcSetupComplete  RRCSetupComplete,  rrcReestablishmentComplete RRCReestablishmentComplete,  rrcResumeComplete  RRCResumeComplete,  securityModeComplete  SecurityModeComplete,  securityModeFailure  SecurityModeFailure,  ulInformationTransfer  ULInformationTransfer,  locationMeasurementIndication LocationMeasurementIndication,  ueCapabilityInformation  UECapabilityInformation,  counterCheckResponse  CounterCheckResponse,  ueAssistanceInformation  UEAssistanceInformation,  failureInformation   FailureInformation,   spare3 NULL,   spare2 NULL,spare1 NULL  },  messageClassExtension   SEQUENCE { } } --TAG-UL-DCCH-MESSAGE-STOP -- ASN1STOP

The NAS 1057 forms the highest stratum of the control plane between theUE 101 and the AMF (e.g., over the N1 reference point). The NAS 1057 maysupport the mobility of the UEs 101 and the session managementprocedures to establish and maintain IP connectivity between the UE 101and a P-GW in LTE systems.

According to various embodiments, one or more protocol entities ofarrangement 1000 may be implemented in UEs 101, RAN nodes 111, AMF in NRimplementations or MME in LTE implementations, UPF in NR implementationsor S-GW and P-GW in LTE implementations, or the like to be used forcontrol plane or user plane communications protocol stack between theaforementioned devices. In such embodiments, one or more protocolentities that may be implemented in one or more of UE 101, gNB 111, AMF,etc. may communicate with a respective peer protocol entity that may beimplemented in or on another device using the services of respectivelower layer protocol entities to perform such communication. In someembodiments, a gNB-CU of the gNB 111 may host the RRC 1055, SDAP 1047,and PDCP 1040 of the gNB that controls the operation of one or moregNB-DUs, and the gNB-DUs of the gNB 111 may each host the RLC 1030, MAC1020, and PHY 810 of the gNB 111.

In a first example, a control plane protocol stack may comprise, inorder from highest layer to lowest layer, NAS 1057, RRC 1055, PDCP 1040,RLC 1030, MAC 1020, and PHY 1110. In this example, upper layers 1060 maybe built on top of the NAS 857, which includes an IP layer 1061, an SCTP1062, and an application layer signaling protocol (AP) 1063.

In NR implementations, the AP 1063 may be an NGAP 1063 for the NGinterface 113 defined between the NG-RAN node 111 and the AMF, or the AP1063 may be an XnAP 1063 for the Xn interface 112 that is definedbetween two or more RAN nodes 111. The NGAP 1063 may support thefunctions of the NG interface 113 and may comprise Elementary Procedures(EPs). An NGAP EP may be a unit of interaction between the NG-RAN node111 and the AMF. The NGAP 1063 services may comprise two groups:UE-associated services (e.g., services related to a UE 101) andnon-UE-associated services (e.g., services related to the whole NGinterface instance between the NG-RAN node 111 and AMF). These servicesmay include functions including, but not limited to: a paging functionfor the sending of paging requests to NG-RAN nodes 111 involved in aparticular paging area; a UE context management function for allowingthe AMF to establish, modify, and/or release a UE context in the AMF andthe NG-RAN node 111; a mobility function for UEs 101 in ECM-CONNECTEDmode for intra-system HOs to support mobility within NG-RAN andinter-system HOs to support mobility from/to EPS systems; a NASSignaling Transport function for transporting or rerouting NAS messagesbetween UE 101 and AMF; a NAS node selection function for determining anassociation between the AMF and the UE 101; NG interface managementfunction(s) for setting up the NG interface and monitoring for errorsover the NG interface; a warning message transmission function forproviding means to transfer warning messages via NG interface or cancelongoing broadcast of warning messages; a Configuration Transfer functionfor requesting and transferring of RAN configuration information (e.g.,SON information, performance measurement data, etc.) between two RANnodes 111 via CN 120; and/or other like functions.

The XnAP 1063 may support the functions of the Xn interface 112 and maycomprise XnAP basic mobility procedures and XnAP global procedures. TheXnAP basic mobility procedures may comprise procedures used to handle UEmobility within the NG RAN 111 (or E-UTRAN 110), such as handoverpreparation and cancellation procedures, SN Status Transfer procedures,UE context retrieval and UE context release procedures, RAN pagingprocedures, dual connectivity related procedures, and the like. The XnAPglobal procedures may comprise procedures that are not related to aspecific UE 101, such as Xn interface setup and reset procedures, NG-RANupdate procedures, cell activation procedures, and the like.

In LTE implementations, the AP 1063 may be an S1 AP 1063 for the S1interface 113 defined between an E-UTRAN node 111 and an MME, or the AP1063 may be an X2AP 1063 for the X2 interface 112 that is definedbetween two or more E-UTRAN nodes 111. The S1AP 1063 may support thefunctions of the S1 interface, and similar to the NGAP discussedpreviously, the S1AP may comprise S1AP EPs. An S1AP EP may be a unit ofinteraction between the E-UTRAN node 111 and an MME within EPC 120. TheS1AP 1063 services may comprise two groups: UE-associated services andnon UE-associated services. These services perform functions including,but not limited to: E-UTRAN Radio Access Bearer (E-RAB) management, UEcapability indication, mobility, NAS signaling transport, RANInformation Management (RIM), and configuration transfer.

The X2AP 1063 may support the functions of the X2 interface 112 and maycomprise X2AP basic mobility procedures and X2AP global procedures. TheX2AP basic mobility procedures may comprise procedures used to handle UEmobility within the E-UTRAN 120, such as handover preparation andcancellation procedures, SN Status Transfer procedures, UE contextretrieval and UE context release procedures, RAN paging procedures, dualconnectivity related procedures, and the like. The X2AP globalprocedures may comprise procedures that are not related to a specific UE101, such as X2 interface setup and reset procedures, load indicationprocedures, error indication procedures, cell activation procedures, andthe like.

The SCTP layer (alternatively referred to as the SCTP/IP layer) 1062 mayprovide guaranteed delivery of application layer messages (e.g., NGAP orXnAP messages in NR implementations, or S1AP or X2AP messages in LTEimplementations). The SCTP 1062 may ensure reliable delivery ofsignaling messages between the RAN node 111 and the AMF/MME based, inpart, on the IP protocol, supported by the IP 1061. The InternetProtocol layer (IP) 1061 may be used to perform packet addressing androuting functionality. In some implementations the IP layer 1061 may usepoint-to-point transmission to deliver and convey PDUs. In this regard,the RAN node 111 may comprise L2 and L1 layer communication links (e.g.,wired or wireless) with the MME/AMF to exchange information.

In a second example, a user plane protocol stack may comprise, in orderfrom highest layer to lowest layer, SDAP 1047, PDCP 1040, RLC 1030, MAC1020, and PHY 1010. The user plane protocol stack may be used forcommunication between the UE 101, the RAN node 111, and UPF in NRimplementations or an S-GW and P-GW in LTE implementations. In thisexample, upper layers 1051 a may be built on top of the SDAP 1047, andmay include UDP/IP 1052, a GTP-U 1053, and a User Plane PDU layer (UPPDU) 1063. The transport layer 1054 (also referred to as a “transportnetwork layer”) may be built on IP transport. The IP layer (alsoreferred to as the “Internet layer”) may be used to perform packetaddressing and routing functionality. The IP layer may assign IPaddresses to user data packets in any of IPv4, IPv6, or PPP formats, forexample.

The GTP-U 1053 may be used on top of the UDP/IP layer 1052 (comprising aUDP layer and IP layer) to carry UP-PDUs. The GTP-U 1053 may be used forcarrying user data within the GPRS core network and between the radioaccess network and the core network. The user data transported can bepackets in any of IPv4, IPv6, or PPP formats, for example. The UDP/IP1052 may provide checksums for data integrity, port numbers foraddressing different functions at the source and destination, andencryption and authentication on the selected data flows. The RAN node111 and the S-GW may utilize an S1-U interface to exchange user planedata via a protocol stack comprising an L1 layer (e.g., PHY 1010), an L2layer (e.g., MAC 1020, RLC 1030, PDCP 1040, and/or SDAP 1047), theUDP/IP layer 1052, and the GTP-U 1053. The S-GW and the P-GW may utilizean S5/S8a interface to exchange user plane data via a protocol stackcomprising an L1 layer, an L2 layer, the UDP/IP layer 1052, and theGTP-U 1053. As discussed previously, NAS protocols may support themobility of the UE 101 and the session management procedures toestablish and maintain IP connectivity between the UE 101 and the P-GW.

In various embodiments, real-time user plane media data is sent overRTP/UDP/IP layers, and non-real-time media may use other transportprotocols such as UDP/IP 1052 or TCP/IP. In these embodiments, upperlayers 1051 b may include UDP/IP 1052, RTP layer 1074, RTCP/SIP/SDPlayer 1075, one or mode media codecs 1076, and conversational multimediaapplication layer 1077. In some embodiments, upper layers 1051 b may bebuilt on top of SDAP 1047 or PDCP 1040. As shown in FIG. 10, RTP 1074and RTCP/SIP/SDP run on top of UDP, but these layers can also run on topof TCP in other embodiments.

The conversational multimedia application layer 1077 includes the mediaapplication(s) that presents or outputs media to the user. The mediacodecs 1076 may be any of the codecs discussed herein (e.g., speech,video, real-time text, etc.). The RTCP/SIP/SDP 1075 involve SIP, SDP,and the SDPCapNeg for session control, media negotiation, andconfiguration functionality as discussed herein. RTP 1074 is used forthe transport of packetized media data. RTP provides real-time deliveryof media data, including functionalities such as packet sequencenumbering and time stamping. The time stamping provides for inter-mediasynchronization in the receiving MTSI client. RTP may include RTCP 1075,which provides QoS monitoring, where each endpoint receives and sendsquality reports from/to the other endpoint including radio capabilitiesand radio-based reports according to the embodiments herein.

SIP 1075 performs the logical bound between the media streams of twoMTSI clients. SIP uses SDP to describe the session properties (e.g., IPaddresses, ports, payload formats, type of media (e.g., audio, video,etc.), media codecs, and session bandwidth). Mobile applications basedon the IETF SIP can be implemented on top of non-IMS networks. In thiscase, only the applications resident in mobile terminals run the SIPprotocol, while the network considers SIP as transport protocol. In 3GPPIMS networks, where SIP has been selected to govern the core callcontrol mechanism, both the network and the mobile terminal implementthe SIP protocol and exchange SIP messages for establishing andreleasing calls. This choice has been made to enable the transitiontowards ALL-IP mobile networks.

Moreover, although not shown by FIG. 10, an application layer may bepresent above the AP 1063 and/or the transport network layer 1054. Theapplication layer may be a layer in which a user of the UE 101, RAN node111, or other network element interacts with software applications beingexecuted, for example, by application circuitry 605 or applicationcircuitry 705, respectively. The application layer may also provide oneor more interfaces for software applications to interact withcommunications systems of the UE 101 or RAN node 111, such as thebaseband circuitry 910. In some implementations the IP layer and/or theapplication layer may provide the same or similar functionality aslayers 5-7, or portions thereof, of the Open Systems Interconnection(OSI) model (e.g., OSI Layer 7—the application layer, OSI Layer 6—thepresentation layer, and OSI Layer 5—the session layer).

FIGS. 12-13 show example procedures 1200-1300, respectively, inaccordance with various embodiments. For illustrative purposes, thevarious operations of processes 1200-1300 is described as beingperformed by a local UE 101, or elements thereof, with respect to aremote UE 101, or elements thereof (e.g., components discussed withregard to platform 700 of FIG. 7). Additionally, the variousmessages/signaling communicated between the UEs 101 may be sent/receivedover the various interfaces and between various intermediary nodes asdiscussed herein with respect to FIGS. 1-11, and using the variousmechanisms discussed herein including those discussed herein withrespect to FIGS. 1-11. While particular examples and orders ofoperations are illustrated FIGS. 12-13, the depicted orders ofoperations should not be construed to limit the scope of the embodimentsin any way. Rather, the depicted operations may be re-ordered, brokeninto additional operations, combined, and/or omitted altogether whileremaining within the spirit and scope of the present disclosure.

FIG. 12 depicts an example procedure 1200 for indicating support of oneor more radio capabilities according to various embodiments. Process1200 begins at operation 1205 where the local UE 101 identifies one ormore capabilities supported by the local UE 101. The one or more radiocapabilities include one or more of a delay budget reporting capability,a TTI bundling capability, a RAN frame aggregation capability, and aRAN-assisted codec adaptation capability or an ANBR signalingcapability. At operation 1210, the local UE 101 generates an SDP messageto indicate the one or more radio capabilities. In some embodiments, theSDP message may include a session level attribute “a=RANCapabilities”,where the RANCapabilities includes individual bits to indicate acorresponding one of the one or more radio capabilities. In otherembodiments, the SDP message may include an individual session levelattribute for each supported radio capability such as “a=anbr” toindicate that the local UE 101 supports the ANBR signaling capability.At operation 1215, the local UE 101 transmits the SDP message to aremote UE 101 b via a RAN node 121. After operation 1215, process 1200may end or repeat as necessary.

FIG. 13 depicts an example procedure 1300 for adjusting a bit rate orbandwidth for consuming media according to various embodiments. Process1300 may be performed by a local UE 101. Process 1300 begins atoperation 1305 where a local UE 101 receives an SDP message from aremote UE 101, and at operation 1310, the local UE 101 identifies one ormore capabilities supported by the remote UE 101 based on the contentsof the SDP message. The one or more radio capabilities include one ormore of a delay budget reporting capability, a TTI bundling capability,a RAN frame aggregation capability, and a RAN-assisted codec adaptationcapability or an ANBR signaling capability. At operation 1315, the localUE 101 determines whether a change in radio conditions has beendetected, and if not, continues to monitor the radio conditions with itslocal RAN node 111. If the radio conditions have changed, the local UE101 proceeds to operation 1320 to generate an SDP message to request achange of one or more radio link parameters. The particular radio linkparameters to be changed, and the extent to which those parameters arechanged may depend on the detected radio conditions and the one or moreradio capabilities supported by the remote UE 101. At operation 1325,the local UE 101 transmits the SDP message to its local RAN node 111 tohave the radio link parameters changed. In some embodiments, the RANnode 111 may send a suitable ACK message to the local UE 101 to indicatethe changed radio link parameters. After operation 1325, process 1300may end or repeat as necessary.

Some non-limiting examples are as follows. The following examplespertain to further embodiments, and specifics in the examples may beused anywhere in one or more embodiments discussed previously. Any ofthe following examples may be combined with any other example or anyembodiment discussed herein.

Example 1 includes a method to be performed by a first UE, the methodcomprising: generating or causing to generate a SDP message to indicateone or more radio capabilities of the first UE; and transmitting orcausing to transmit the SDP message to a second UE via a RAN node.

Example 2 includes the method of example 1 and/or some other example(s)herein, wherein the SDP message is a first SDP message, the one or moreradio capabilities of the first UE are first radio capabilities, and themethod comprises: identifying or causing to identify one or more secondradio capabilities of the second UE within a second SDP message obtainedfrom the second UE; and determining or causing to determine one or moredesired radio level adaptations based on the one or more second radiocapabilities.

Example 3 includes the method of example 2 and/or some other example(s)herein, wherein the method comprises: determining or causing todetermine the one or more desired radio level adaptations based on theone or more second radio capabilities and based on detected radioconditions.

Example 4 includes the method of example 3 and/or some other example(s)herein, wherein the detected radio conditions are one or both ofconditions of a radio link between the first UE and the RAN node andconditions of a radio link between the second UE and another RAN node.

Example 5 includes the method of examples 3-4 and/or some otherexample(s) herein, wherein the method comprises: generating or causingto generate an RRC message to indicate a desired radio level adaptation;and transmitting or causing to transmit the RRC message to the RAN node.Example 6 includes the method of example 5 and/or some other example(s)herein, wherein the desired radio level adaptation is to turn off cDRXwhen the one or more second radio capabilities indicate support of DBIsignaling and TTI bundling, the detected radio conditions are betterthan threshold radio conditions, and an e2e packet loss rate is below athreshold e2e packet loss rate. Example 7 includes the method ofexamples 5-6 and/or some other example(s) herein, wherein the RRCmessage is to include a UE Assistance Information(UEAssistanceInformation) IE, and the UEAssistanceInformation IE is toindicate the desired radio level adaptation.

Example 8 includes the method of examples 2-3 and/or some otherexample(s) herein, wherein the method comprises: generating or causingto generate a first recommended bit rate MAC CE, the first recommendedbit rate MAC CE to query for a recommended bit rate or indicate adesired radio level adaptation; transmitting or causing to transmit thefirst recommended bit rate MAC CE to the RAN node; and receiving asecond recommended bit rate MAC CE from the RAN node, the secondrecommended bit rate MAC CE to include ANBR information.

Example 9 includes the method of example 8 and/or some other example(s)herein, wherein the method comprises: adapting or causing to adapt a bitrate based on the ANBR information; generating or causing to generate aCMR or an RTCP-APP for voice rate adaptation based on the ANBRinformation; and/or generating or causing to generate a TMMBR or a TMMBNmessage for video rate adaptation based on the ANBR information.

Example 10 includes the method of examples 2-9 and/or some otherexample(s) herein, wherein the first SDP message is an SDP offer messageand the second SDP message is an SDP answer message, or the second SDPmessage is an SDP offer message and the first SDP message is an SDPanswer message.

Example 11 includes the method of example 10, wherein the methodcomprises: generating or causing to generate the first SDP message toinclude a first radio capabilities attribute to indicate the one or morefirst radio capabilities; and identifying or causing to identify the oneor more second radio capabilities within a second radio capabilitiesattribute in the second SDP message.

Example 12 includes the method of examples 1-11 and/or some otherexample(s) herein, wherein the one or more radio capabilities includeone or more of a delay budget reporting capability, a TTI bundlingcapability, a RAN frame aggregation capability, and a RAN-assisted codecadaptation capability or an ANBR signaling capability.

Example 13 includes a method to be performed by a first MTSI client interminal, the method comprising: generating or causing to generate a SDPmessage to indicate one or more RAN-level radio capabilities of thefirst UE; and transmitting or causing to transmit the SDP message to asecond MTSI client in terminal via a radio link between the first MTSIclient in terminal and a RAN node.

Example 14 includes the method of example 13 and/or some otherexample(s) herein, wherein the SDP message is a first SDP message, theone or more radio capabilities of the first MTSI client in terminal arefirst radio capabilities, and the method comprises: identifying orcausing to identify one or more second radio capabilities of the secondMTSI client in terminal within a second SDP message obtained from thesecond MTSI client in terminal; and determining or causing to determineone or more desired radio level adaptations based on the one or moresecond radio capabilities and based on detected radio conditions,wherein the detected radio conditions are one or both of conditions ofthe radio link between the first MTSI client in terminal and the RANnode and conditions of a radio link between the second MTSI client interminal and another RAN node.

Example 15 includes the method of example 14 and/or some otherexample(s) herein, wherein the method comprises: generating or causingto generate a RRC message to indicate a desired radio level adaptation;and transmitting or causing to transmit the RRC message to the RAN node.

Example 16 includes the method of example 15 and/or some otherexample(s) herein, wherein the desired radio level adaptation is to turnoff cDRX when the one or more second radio capabilities indicate supportof DBI signaling and TTI bundling, the detected radio conditions arebetter than threshold radio conditions, or an e2e packet loss rate isbelow a threshold e2e packet loss rate. Example 17 includes the methodof examples 15-16 and/or some other example(s) herein, wherein the RRCmessage is to include a UEAssistanceInformation IE, and theUEAssistanceInformation IE is to indicate the desired radio leveladaptation.

Example 18 includes the method of example 14 and/or some otherexample(s) herein, wherein the method comprises: generating or causingto generate a recommended bit rate MAC CE to include a recommended bitrate query, the recommended bit rate query to query for a recommendedbit rate or indicate a desired radio level adaptation; transmitting orcausing to transmit the recommended bit rate MAC CE including therecommended bit rate query to the RAN node; and receiving, from the RANnode, a recommended bit rate MAC CE that includes a recommended bit ratemessage, the recommended bit rate message to indicate an ANBR, and theANBR is based on the recommended bit rate query.

Example 19 includes the method of example 18 and/or some otherexample(s) herein, wherein the method comprises: adapting or causing toadapt a bit rate based on the ANBR; generating or causing to generate aCMR or an RTCP-APP for voice rate adaptation based on the ANBR; orgenerating or causing to generate a TMMBR or a TMMBN message for videorate adaptation based on the ANBR.

Example 20 includes the method of examples 13-19 and/or some otherexample(s) herein, wherein the first SDP message is an SDP offer messageand the second SDP message is an SDP answer message, or the second SDPmessage is an SDP offer message and the first SDP message is an SDPanswer message, and wherein the method comprises: generating or causingto generate the first SDP message to include a first radio capabilitiesattribute to indicate the one or more first radio capabilities; andidentifying or causing to identify the one or more second radiocapabilities within a second radio capabilities attribute in the secondSDP message.

Example 21 includes the method of examples 13-20 and/or some otherexample(s) herein, wherein the one or more radio capabilities includeone or more of a delay budget reporting capability, a TTI bundlingcapability, a RAN frame aggregation capability, and a RAN-assisted codecadaptation capability or an ANBR signaling capability.

Example 22 includes a method to be performed by a MTSI client interminal comprising: identifying or causing to identify radiocapabilities of a remote device based on a session description protocol(SDP) offer message obtained from the remote device; and generating orcausing to generate an SDP answer message to include a radiocapabilities attribute, the radio capabilities attribute to indicate oneor more radio capabilities of the apparatus.

Example 23 includes the method of example 22 and/or some otherexample(s) herein, further comprising: receiving the SDP offer messagefrom the remote device, wherein the SDP offer message is to includeanother radio capabilities attribute of the remote device; andtransmitting or causing to transmit the SDP answer message to the remotedevice. Example 24 includes the method of example 23 and/or some otherexample(s) herein, wherein the radio capabilities attribute of theapparatus is to indicate whether the apparatus supports one or more of adelay budget reporting, TTI bundling, RAN frame aggregation, andRAN-assisted codec adaptation or an ANBR signaling capability; and theother radio capabilities attribute of the remote device is to indicatewhether the remote device supports one or more of a delay budgetreporting, TTI bundling, RAN frame aggregation, and RAN-assisted codecadaptation or an ANBR signaling capability.

Example 25 includes the method of example 24 and/or some otherexample(s) herein, further comprising: detecting or causing to detectradio conditions local to the MTSI client in terminal, wherein thedetected radio conditions are one or both of conditions of the radiolink between the MTSI client in terminal and the RAN node and conditionsof a radio link between the remote device and another RAN node; andgenerating or causing to generate a message to indicate one or moredesired radio level adaptations based on the radio capabilities of theremote device and based on the detected radio conditions.

Example 26 includes the method of example 25 and/or some otherexample(s) herein, wherein the message is an RRC message, and the methodcomprises: transmitting or causing to transmit the RRC message to alocal RAN node; receiving another message from the RAN node based on theRRC message; and adjusting or causing to adjust a bit rate based on themessage received from the RAN node. Example 27 includes the method ofexample 26 and/or some other example(s) herein, wherein when thedetected radio conditions include a relatively long packet delay andjitter, the other message is a recommended bit rate MAC CE; and when thedetected radio conditions include a relatively large number of packetlosses, the other message is a delay budget information acknowledgementindicating that additional budget has been granted by the RAN node.

Example 28 includes the method of example 25 and/or some otherexample(s) herein, wherein the message is a recommended bit rate queryMAC CE for querying the recommended bitrate or indicating a desired bitrate, and the method comprises receiving a recommended bit rate messageMAC CE, the recommended bit rate message MAC CE including an ANBR basedon the recommended bit rate query MAC CE. Example 29 includes the methodof example 28 and/or some other example(s) herein, further comprising:adapting or causing to adapt a bit rate based on the ANBR. Example 30includes the method of examples 28-29 and/or some other example(s)herein, wherein the method comprises: generating or causing to generatea CMR or an Application-defined RTCP-APP for voice rate adaptation basedon the ANBR; and/or generating or causing to generate a TMMBR or a TMMBNmessage for video rate adaptation based on the ANBR.

Example 31 may include an apparatus comprising means to perform one ormore elements of a method described in or related to any of examples1-30, or any other method or process described herein. Example 32 mayinclude one or more non-transitory computer-readable media comprisinginstructions to cause an electronic device, upon execution of theinstructions by one or more processors of the electronic device, toperform one or more elements of a method described in or related to anyof examples 1-30, or any other method or process described herein.Example 33 may include an apparatus comprising logic, modules, orcircuitry to perform one or more elements of a method described in orrelated to any of examples 1-30, or any other method or processdescribed herein. Example 34 may include a method, technique, or processas described in or related to any of examples 1-30, or portions or partsthereof. Example 35 may include an apparatus comprising: one or moreprocessors and one or more computer-readable media comprisinginstructions that, when executed by the one or more processors, causethe one or more processors to perform the method, techniques, or processas described in or related to any of examples 1-30, or portions thereof.Example 36 may include a signal as described in or related to any ofexamples 1-30, or portions or parts thereof. Example 37 includes apacket, frame, segment, PDU, or message as described in or related toany of examples 1-30, or portions or parts thereof, or otherwisedescribed in the present disclosure. Example 38 may include a signal ina wireless network as shown and described herein. Example 39 may includea method of communicating in a wireless network as shown and describedherein. Example 40 may include a system for providing wirelesscommunication as shown and described herein. Example 41 may include adevice for providing wireless communication as shown and describedherein.

In the preceding detailed description, reference is made to theaccompanying drawings which form a part hereof wherein like numeralsdesignate like parts throughout, and in which is shown by way ofillustration embodiments that may be practiced. It is to be understoodthat other embodiments may be utilized and structural or logical changesmay be made without departing from the scope of the present disclosure.Therefore, the detailed description is not to be taken in a limitingsense, and the scope of embodiments is defined by the appended claimsand their equivalents.

Various operations may be described as multiple discrete actions oroperations in turn, in a manner that is most helpful in understandingthe claimed subject matter. However, the order of description should notbe construed as to imply that these operations are necessarily orderdependent. In particular, these operations may not be performed in theorder of presentation. Operations described may be performed in adifferent order than the described embodiment. Various additionaloperations may be performed and/or described operations may be omittedin additional embodiments. Also, it is noted that example embodimentsmay be described as a process depicted as successive operations and/orwith a flowchart, a flow diagram, a data flow diagram, a structurediagram, or a block diagram. Although a flowchart may describe theoperations as a sequential process, many of the operations may beperformed in parallel, concurrently, or simultaneously. In addition, theorder of the operations may be re-arranged. A process may be terminatedwhen its operations are completed, but may also have additional stepsnot included in a figure. A process may correspond to a method, afunction, a procedure, a subroutine, a subprogram, and the like. When aprocess corresponds to a function, its termination may correspond to areturn of the function to the calling function a main function.

The flowchart and block diagrams in the figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present disclosure. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the disclosure.The singular forms “a,” “an” and “the” are intended to include pluralforms as well, unless the context clearly indicates otherwise. It willbe further understood that the terms “comprises” and/or “comprising,”when used in this specification, specific the presence of statedfeatures, integers, steps, operations, elements, and/or components, butdo not preclude the presence or addition of one or more other features,integers, steps, operation, elements, components, and/or groups thereof.For the purposes of the present disclosure, the phrase “A and/or B”means (A), (B), or (A and B). For the purposes of the presentdisclosure, the phrase “A, B, and/or C” means (A), (B), (C), (A and B),(A and C), (B and C), or (A, B and C). The description may use thephrases “in an embodiment,” or “In some embodiments,” which may eachrefer to one or more of the same or different embodiments. Furthermore,the terms “comprising,” “including,” “having,” and the like, as usedwith respect to embodiments of the present disclosure, are synonymous.Where the disclosure recites “a” or “a first” element or the equivalentthereof, such disclosure includes one or more such elements, neitherrequiring nor excluding two or more such elements. Further, ordinalindicators (e.g., first, second or third) for identified elements areused to distinguish between the elements, and do not indicate or imply arequired or limited number of such elements, nor do they indicate aparticular position or order of such elements unless otherwisespecifically stated.

The terms “coupled,” “communicatively coupled,” along with derivativesthereof are used herein. The term “coupled” may mean two or moreelements are in direct physical or electrical contact with one another,may mean that two or more elements indirectly contact each other butstill cooperate or interact with each other, and/or may mean that one ormore other elements are coupled or connected between the elements thatare said to be coupled with each other. The term “directly coupled” maymean that two or more elements are in direct contact with one another.The term “communicatively coupled” may mean that two or more elementsmay be in contact with one another by a means of communication includingthrough a wire or other interconnect connection, through a wirelesscommunication channel or ink, and/or the like.

The term “circuitry” refers to a circuit or system of multiple circuitsconfigured to perform a particular function in an electronic device. Thecircuit or system of circuits may be part of, or include one or morehardware components, such as a logic circuit, a processor (shared,dedicated, or group) and/or memory (shared, dedicated, or group) thatare configured to provide the described functionality. In addition, theterm “circuitry” may also refer to a combination of one or more hardwareelements with the program code used to carry out the functionality ofthat program code. Some types of circuitry may execute one or moresoftware or firmware programs to provide at least some of the describedfunctionality. Such a combination of hardware elements and program codemay be referred to as a particular type of circuitry. The term“processor circuitry” refers to, is part of, or includes circuitrycapable of sequentially and automatically carrying out a sequence ofarithmetic or logical operations, or recording, storing, and/ortransferring digital data. and/or any other device capable of executingor otherwise operating computer-executable instructions, such as programcode, software modules, and/or functional processes. The term “module”may refer to one or more independent electronic circuits packaged onto acircuit board, System-on-Chip (SoC), System-in-Package (SiP),Multi-Chip-Package (MCP), etc., configured to provide a basic functionwithin a computer system. The term “module” may refer to, be part of, orinclude an FPGA, ASIC, a processor (shared, dedicated, or group) and/ormemory (shared, dedicated, or group) that execute one or more softwareor firmware programs, a combinational logic circuit, and/or othersuitable components that provide the described functionality. The term“interface circuitry” may refer to, is part of, or includes circuitryproviding for the exchange of information between two or more componentsor devices. The term “interface circuitry” may refer to one or morehardware interfaces (e.g., buses, I/O interfaces, peripheral componentinterfaces, network interface cards, and/or the like). The term “memory”and/or “memory circuitry” may represent one or more hardware devices forstoring data, including RAM, magnetic RAM, core memory, ROM, magneticdisk storage mediums, optical storage mediums, flash memory devices orother machine readable mediums for storing data. The term“computer-readable medium” may include, but is not limited to, memory,portable or fixed storage devices, optical storage devices, and variousother mediums capable of storing, containing or carrying instructions ordata.

The term “device” refers to a physical entity embedded inside, orattached to, another physical entity in its vicinity, with capabilitiesto convey digital information from or to that physical entity. The term“element” refers to a unit that is indivisible at a given level ofabstraction and has a clearly defined boundary, wherein an element maybe any type of entity. The term “controller” refers to an element orentity that has the capability to affect a physical entity, such as bychanging its state or causing the physical entity to move. The term“entity” refers to a distinct component of an architecture or device,and/or information transferred as a payload. The term “network element”as used herein refers to physical or virtualized equipment and/orinfrastructure used to provide wired or wireless communication networkservices. The term “network element” may be considered synonymous toand/or referred to as a networked computer, networking hardware, networkequipment, network node, router, switch, hub, bridge, radio networkcontroller, RAN device, RAN node, gateway, server, virtualized VNF,NFVI, and/or the like. The terms “access node,” “access point,” or thelike may describe equipment that provides the radio baseband functionsfor data and/or voice connectivity between a network and one or moreusers.

The term “computer system” refers to any type interconnected electronicdevices, computer devices, or components thereof. Additionally, the term“computer system” and/or “system” refers to various components of acomputer that are communicatively coupled with one another, or otherwiseorganized to accomplish one or more functions. Furthermore, the term“computer system” and/or “system” refers to multiple computer devicesand/or multiple computing systems that are communicatively coupled withone another and configured to share computing and/or networkingresources. The term “architecture” refers to a fundamental organizationof a system embodied in its components, their relationships to oneanother, and to an environment, as well as to the principles guiding itsdesign and evolution. The term “user equipment” or “UE” as used hereinrefers to a device with radio communication capabilities and maydescribe a remote user of network resources in a communications network.The term “user equipment” or “UE” may be considered synonymous to, andmay be referred to as, client, mobile, mobile device, mobile terminal,user terminal, mobile unit, mobile station, mobile user, subscriber,user, remote station, access agent, user agent, receiver, radioequipment, reconfigurable radio equipment, reconfigurable mobile device,etc. Furthermore, the term “user equipment” or “UE” may include any typeof wireless/wired device or any computing device including a wirelesscommunications interface.

The term “channel” as used herein refers to any transmission medium,either tangible or intangible, which is used to communicate data or adata stream. The term “channel” may be synonymous with and/or equivalentto “communications channel,” “data communications channel,”“transmission channel,” “data transmission channel,” “access channel,”“data access channel,” “link,” “data link,” “carrier,” “radiofrequencycarrier,” and/or any other like term denoting a pathway or mediumthrough which data is communicated. Additionally, the term “link” asused herein refers to a connection between two devices through a RAT forthe purpose of transmitting and receiving information. The term“communication protocol” (either wired or wireless) refers to a set ofstandardized rules or instructions implemented by a communication deviceand/or system to communicate with other devices and/or systems,including instructions for packetizing/depacketizing data,modulating/demodulating signals, implementation of protocols stacks,and/or the like.

The terms “instantiate,” “instantiation,” and the like refers to thecreation of an instance, and an “instance” refers to a concreteoccurrence of an object, which may occur, for example, during executionof program code. The term “information element” refers to a structuralelement containing one or more fields. The term “field” refers toindividual contents of an information element, or a data element thatcontains content. The term “resource” refers to a physical or virtualdevice, a physical or virtual component within a computing environment,and/or a physical or virtual component within a particular device, suchas computer devices, mechanical devices, memory space, processor/CPUtime, processor/CPU usage, processor and accelerator loads, hardwaretime or usage, electrical power, I/O operations, ports or networksockets, channel/link allocation, throughput, memory usage, storage,network, database and applications, workload units, and/or the like. Theterm “service” refers to a particular functionality or a set offunctions to be performed on behalf of a requesting party, such as anyof the computing systems or devices discussed herein. A service mayinclude or involve the retrieval of specified information or theexecution of a set of operations. The term “session” refers to a set ofsenders and receivers, and the data streams flowing from the senders toreceivers. The term “session description” refers to a format forconveying sufficient information to discover and participate in amultimedia session. A “media stream” refers to a single media instance,for example, an audio stream or a video stream, as well as a singlewhiteboard or shared application group.

For the purposes of the present document, the abbreviations listed intable 10 may apply to the examples and embodiments discussed herein.

TABLE 10 3GPP Third Generation Partnership Project 4G Fourth Generation5G Fifth Generation 5GC 5G Core Network ACK Acknowledgement AFApplication Function AM Acknowledged Mode AMF Access and MobilityManagement Function AMR Adaptive Multi-Rate AMR-NB Adaptive Multi-Rate -NarrowB and AMR-WB Adaptive Multi-Rate ? WideBand AMR-WB IO AdaptiveMulti-Rate - WideBand Inter-operable Mode AN Access Network ANBR AccessNetwork Bitrate Recommendation ANBRQ Access Network BitrateRecommendation Query AP Application Protocol, Antenna Port, Access PointAPI Application Programming Interface APP Application-defined RTCPpacket ARQ Automatic Repeat Request AS Access Stratum AS ApplicationServer ASN.1 Abstract Syntax Notation One AUSF Authentication ServerFunction AVC Advanced Video Coding AVP Audio-Visual Profile AVPF AVPwith Feedback BER Bit Error Ratio BLER Block Error Rate BS Base StationBW Bandwidth CA Carrier Aggregation, Certification Authority CAMELCustomised Application Mobile Enhanced Logic CAP Camel Application PartCAPEX CAPital Expenditure CCM Codec Control Messages CDF CumulativeDistribution Function CDMA Code-Division Multiple Access CDR ChargingData Record cDRX Connected Mode DRX CID Cell-ID (e.g., positioningmethod) CM Connection Management, Conditional Mandatory CMR Codec ModeRequest CPU CSI processing unit, Central Processing Unit CRAN CloudRadio Access Network, Cloud RAN CS Circuit Switched CS-ACELPConjugate-Structure Algebraic-Code-Excited Linear Prediction CSCF CallSession Control Function D2D Device-to-Device DBI Delay BudgetInformation DECT Digital Enhanced Cordless Telecommunications DFDeployment Flavour DL Downlink DMTF Distributed Management Task Force DNData network DRX Discontinuous Reception DSR Distributed SpeechRecognition DTMF Dual Tone Multi-Frequency DTX DiscontinuousTransmission e2e End-to-End ECN Explicit Congestion Notification ECN-CEECN Congestion Experienced ECT ECN Capable Transport eNB evolved NodeB,E-UTRAN Node B EPC Evolved Packet Core EPS Evolved Packet System E-UTRAEvolved UTRA E-UTRAN Evolved UTRAN EVRC Enhanced Variable Rate Codec EVSEnhanced Voice Services FDD Frequency Division Duplex FDM FrequencyDivision Multiplex FDMA Frequency Division Multiple Access FEM Front EndModule FPGA Field-Programmable Gate Array FR Frequency Range GBRGuaranteed Bit Rate GERAN GSM EDGE RAN, GSM EDGE Radio Access NetworkGLONASS GLObal'naya NAvigatsionnaya Sputnikovaya Sistema (Engl.: GlobalNavigation Satellite System) gNB Next Generation NodeB gNB-CUgNB-centralized unit gNB-DU gNB-distributed unit GNSS Global NavigationSatellite System GPRS General Packet Radio Service GRUU GloballyRoutable UA URI GSM Global System for Mobile Communications, GroupeSpécial Mobile GTP GPRS Tunneling Protocol GTP-U GPRS TunnellingProtocol for User Plane HARQ Hybrid ARQ, Hybrid Automatic Repeat RequestHEVC High Efficiency Video Coding HSS Home Subscriber Server HTTP HyperText Transfer Protocol HTTPS Hyper Text Transfer Protocol Secure (httpsis http/1.1 over SSL, e.g., port 443) I-CSCF Interrogating CSCF IM-SSFIMS Service Switching Function ICM Initial Codec Mode ID Identity,identifier IE Information Element IEEE Institute of Electrical andElectronics Engineers IETF Internet Engineering Task Force JIMInterference Measurement, Intermodulation, IP Multimedia IMC IMSCredentials IMS IP Multimedia Subsystem IoT Internet of Things I/OInput/Output IP Internet Protocol IPsec IP Security, Internet ProtocolSecurity IP-CAN IP-Connectivity Access Network IPv4 Internet ProtocolVersion 4 IPv6 Internet Protocol Version 6 IR Infrared ISO InternationalOrganisation for Standardisation IWF Interworking-Function I-WLANInterworking WLAN JBM Jitter Buffer Management kB Kilobyte (1000 bytes)kbps kilo-bits per second ksps kilo-symbols per second L1 Layer 1(physical layer) L2 Layer 2 (data link layer) L3 Layer 3 (network layer)LAN Local Area Network LLC Logical Link Control, Low Layer CompatibilityLPLMN Local PLMN LSB Least Significant Bit LIE Long Term Evolution LWALTE-WLAN aggregation LWIP LTE/WLAN Radio Level Integration with IPsecTunnel LIE Long Term Evolution M2M Machine-to-Machine MAC Medium AccessControl, Media Access Control (protocol layering context) MBR MaximumBit Rate MFRC Media Resource Function Controller MFRP Media ResourceFunction Processor MGW Media Gateway MIB Master Information Block,Management Information Base MIMO Multiple Input Multiple Output MMMobility Management MME Mobility Management Entity MPDCCH MTC PhysicalDownlink Control CHannel MPEG Moving Picture Experts Group MPLSMultiProtocol Label Switching MSB Most Significant Bit MSMTSIMulti-Stream Multimedia Telephony Service for IMS MTSI MultimediaTelephony Service for IMS MTC Machine-Type Communications mMTC massiveMTC, massive Machine-Type Communications N3GPP Non-3 GPP, Non-ThirdGeneration Partnership Project N3IWF Non-3 GPP InterWorking FunctionNACK Negative Acknowledgement NAS Non-Access Stratum NEF NetworkExposure Function NF Network Function NFV Network FunctionsVirtualization NFVI NFV Infrastructure NFVO NFV Orchestrator NG NextGeneration, Next Gen NGAP NG Application Protocol NG-DECT New GenerationDECT NGEN-DC NG-RAN E-UTRA-NR Dual Connectivity NR New Radio, NeighbourRelation NSSAI Network Slice Selection Assistance Information S-NNSAISingle-NSSAI NSSF Network Slice Selection Function NW Network OFDMOrthogonal Frequency Division Multiplexing OFDMA Orthogonal FrequencyDivision Multiple Access OSA Open Services Architecture, Open ServicesAccess OTA Over-the-Air P-GRUU Public GRUU PCC Policy and ChargingControl (IMS contexts) PCEF Policy and Charging Enforcement Function PCFPolicy Control Function PCRF Policy Control and Charging Rules FunctionPDCP Packet Data Convergence Protocol PDCCH Physical Downlink ControlChannel PDCP Packet Data Convergence Protocol PDN Packet Data Network,Public Data Network PDSCH Physical Downlink Shared Channel PDU ProtocolData Unit P-GW PDN Gateway P-CSCF Proxy CSCF PHY Physical layer PLMNPublic Land Mobile Network PLR Packet Loss Rate POC PTT over CellularPP, PTP Point-to-Point PPP Point-to-Point Protocol ProSe ProximityServices, Proximity-Based Service PSBCH Physical Sidelink BroadcastChannel PSDCH Physical Sidelink Downlink Channel PSCCH Physical SidelinkControl Channel PSSCH Physical Sidelink Shared Channel PTT Push-to-TalkPUCCH Physical Uplink Control Channel PUSCH Physical Uplink SharedChannel QoS Quality of Service RAN Radio Access Network RAT Radio AccessTechnology Rel Release RF Radio Frequency RLC Radio Link Control RNCRadio Network Controller RRC Radio Resource Control RSU Road Side UnitRTCP RTP Control Protocol, Real-Time Transport Control Protocol RTP RealTime Protocol RTSP RTP Streaming Protocol RTT Round Trip Time RxReception, Receiving, Receiver S1AP S1 Application Protocol S1-MME S1for the control plane S1-U S1 for the user plane S-CSCF Serving CSCFS-GW Serving Gateway SAE System Architecture Evolution SAP ServiceAccess Point SC-FDMA Single Carrier Frequency Division Multiple AccessSCS Service Capability Servers SCTP Stream Control Transmission ProtocolSDAP Service Data Adaptation Protocol, Service Data Adaptation Protocollayer SDP Service Description Protocol SDPCapNeg SDP CapabilityNegotiation SEAF Security Anchor Function SEPP Security Edge ProtectionProxy SGSN Serving GPRS Support Node S-GW Serving Gateway SI SystemInformation SIB System Information Block SIP Session Initiation ProtocolSL Sidelink SM Session Management SMF Session Management Function SMSShort Message Service SPS Semi-Persistent Scheduling SRTP Secure RTPSRVCC Single Radio Voice Call Continuity T-GRUU Temporary GRUU TBD To BeDefined TCP Transmission Communication Protocol TLS Transport LayerSecurity TM Transparent Mode TMMBN Temporary Maximum Media Bit-rateNotification TMMBR Temporary Maximum Media Bit-rate Request TR TechnicalReport TRP, TRxP Transmission Reception Point TRx Transceiver TSTechnical Specifications, Technical Standard TTI Transmission TimeInterval Tx Transmission, Transmitting, Transmitter UA User Agent UEUser Equipment UDM Unified Data Management UDP User Datagram ProtocolUDSF Unstructured Data Storage Network Function UL Uplink UMUnacknowledged Mode UML Unified Modelling Language UMTS Universal MobileTelecommunications System UP User Plane UPF User Plane Function URIUniform Resource Identifier URL Uniform Resource Locator USB UniversalSerial Bus USIM Universal Subscriber Identity Module UTRA UMTSTerrestrial Radio Access UTRAN Universal Terrestrial Radio AccessNetwork V2X Vehicle-to-everything vBBUP virtual baseband unit pool ViLTEVideo-over-LTE VoIP Voice-over-IP, Voice-over-Internet Protocol VoLTEVoice-over-LTE VM Virtual Machine VNF Virtualized Network Function VPLMNVisited Public Land Mobile Network WiMAX Worldwide Interoperability forMicrowave Access WLAN Wireless Local Area Network WMAN WirelessMetropolitan Area Network WPAN Wireless Personal Area Network X2AP X2Application Protocol X2-C X2 Control plane X2-U X2 User plane XnAP XnApplication Protocol Xn-C Xn Control plane Xn-U Xn User plane XMLeXtensible Markup Language

The foregoing description provides illustration and description ofvarious example embodiments, but is not intended to be exhaustive or tolimit the scope of embodiments to the precise forms disclosed.Modifications and variations are possible in light of the aboveteachings or may be acquired from practice of various embodiments. Itshould be understood that there is no intent to limit the concepts ofthe present disclosure to the particular forms disclosed, but on thecontrary, the intention is to cover all modifications, equivalents, andalternatives consistent with the present disclosure and the appendedclaims.

1-25. (canceled)
 26. A user equipment (UE) comprising: memory circuitryto store program code of a Multimedia Telephony Service for InternetProtocol Multimedia Subsystem (MTSI) client; and processor circuitrycoupled with the memory circuitry, the processor circuitry to operatethe MTSI client to: generate a Session Description Protocol (SDP)message to indicate support for one or more radio capabilities, the oneor more radio capabilities including an access network bitraterecommendation (ANBR) capability, and send the SDP message to anotherMTSI client operated by another UE.
 27. The UE of claim 26, wherein theprocessor circuitry is to operate the MTSI client to: generate the SDPmessage to include a media-level SDP attribute of ‘anbr’ to indicate theANBR capability.
 28. The UE of claim 27, wherein the processor circuitryis further to operate the MTSI client to: generate the SDP message toinclude the media-level SDP attribute of ‘anbr’ when the MTSI clientsupports ANBR including use of ANBR with dynamic bitrate adaptation. 29.The UE of claim 28, wherein the processor circuitry is further tooperate the MTSI client to: generate the SDP message to include themedia-level SDP attribute of ‘anbr’ further when the MTSI clientsupports radio access network (RAN)-assisted codec adaptation.
 30. TheUE of claim 29, wherein the processor circuitry is further to operatethe MTSI client to: generate the SDP message to include the media-levelSDP attribute of ‘anbr’ further when the UE is able to query and receiveANBR information for uplink and downlink from a serving base station.31. The UE of claim 27, wherein the SDP message is a first SDP message,the one or more radio capabilities are first radio capabilities, andwherein the processor circuitry is further to operate the MTSI clientto: identify one or more second radio capabilities of the other UEwithin a second SDP message obtained from the other UE; and determinethat the other UE supports the ANBR capability when the one or moresecond radio capabilities includes the ANBR capability.
 32. The UE ofclaim 31, wherein the processor circuitry is further to operate the MTSIclient to: obtain an ANBR message when the other UE supports the ANBRcapability.
 33. The UE of claim 32, wherein the ANBR message is totrigger an adaptation decision for a local uplink channel or a localdownlink channel.
 34. The UE of claim 32, wherein the processorcircuitry is further to operate the MTSI client to: determine acurrently allowed bitrate from the obtained ANBR message.
 35. The UE ofclaim 32, wherein the ANBR message is a recommended bit rate mediumaccess control (MAC) control element.
 36. One or more non-transitorycomputer-readable media (NTCRM) comprising instructions, whereinexecution of the instructions by one or more processors of a first userequipment (UE) is to cause the first UE to: generate a SessionDescription Protocol (SDP) message to indicate support for an accessnetwork bitrate recommendation (ANBR) capability; and send the SDPmessage to a second UE.
 37. The one or more NTCRM of claim 36, whereinexecution of the instructions is to cause the first UE to: generate theSDP message to include a media-level SDP attribute of ‘anbr’ to indicatethe ANBR capability.
 38. The one or more NTCRM of claim 37, whereinexecution of the instructions is to cause the first UE to: generate theSDP message to include the media-level SDP attribute of ‘anbr’ when theMTSI client supports ANBR including use of ANBR with dynamic bitrateadaptation.
 39. The one or more NTCRM of claim 38, wherein execution ofthe instructions is to cause the first UE to: generate the SDP messageto include the media-level SDP attribute of ‘anbr’ further when the MTSIclient supports radio access network (RAN)-assisted codec adaptation.40. The one or more NTCRM of claim 38, wherein execution of theinstructions is to cause the first UE to: generate the SDP message toinclude the media-level SDP attribute of ‘anbr’ further when the UE isable to query and receive ANBR information for uplink and downlink froma serving base station.
 41. The one or more NTCRM of claim 37, whereinthe SDP message is a first SDP message, the one or more radiocapabilities are first radio capabilities, and execution of theinstructions is to cause the first UE to: identify one or more secondradio capabilities of the other UE within a second SDP message obtainedfrom the other UE; and determine that the other UE supports the ANBRcapability when the one or more second radio capabilities includes theANBR capability.
 42. The one or more NTCRM of claim 41, whereinexecution of the instructions is to cause the first UE to: obtain anANBR message from a serving base station when the other UE supports theANBR capability.
 43. A user equipment (UE) comprising: memory circuitryto store program code of a Multimedia Telephony Service for InternetProtocol Multimedia Subsystem (MTSI) client in terminal; and processorcircuitry coupled with the memory circuitry, the processor circuitry tooperate the MTSI client in terminal to: identify an access networkbitrate recommendation (ANBR) capability of a remote device from asession description protocol (SDP) offer message obtained from theremote device, generate an SDP answer message to indicate support of theANBR capability by the UE, and send the SDP answer message to the remotedevice.
 44. The UE of claim 43, wherein the processor circuitry is tooperate the MTSI client in terminal to: generate the SDP answer messageto include a media-level SDP attribute of ‘anbr’ to indicate the supportof the ANBR capability.
 45. The UE of claim 44, wherein the processorcircuitry is to operate the MTSI client in terminal to: generate the SDPanswer message to include the media-level SDP attribute of ‘anbr’ whenthe MTSI client supports ANBR including use of ANBR with dynamic bitrateadaptation and when the MTSI client supports radio access network(RAN)-assisted codec adaptation.